Shadowmage

[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

Recommended Posts

@ShadowmageOk, thats really early wip and quite ugly, render are maya-software garbage and as a prof of concept its kinda bad.  but I think that with some effort I might be able to explain what I have in mind.

AaWyymZ.jpg

The 4 bottom one are basically 3 seperated part, and in a darker gray, editable fairing. Given how existing SSTU part works it could be a single one. Light gray are scaled proportionaly, animated traps and leg could be placed there without discarding the fairing. Dark gray are fairing , jetisonable or not, technically there would be way to make them animated door but I will leave that part aside for simplicity.

As for the different shapes, it is controlled trough 5 joints for the frame, 5 for the fairing, scaled in X Y, plus Z for the nose, frame and fairing can be scaled together, I will explain that later. Every joints are at the center of symmetry control a single edge loop around the Z axis, the first and last joint control ends scale as well. Bottom two are larger and progressively scaled in X, note that it would be a problem for traps. Middle one have a ballistic shape trough X and Y, and so on... Top one is there to to give a idea of what it would look like if two would be jointed together. Scaling joints if fairly basic stuff, the shape could have been round, rounded top with flat bottom or even a much more complex shape, as long as joints are aligned it will work.

That's how it work in maya. As for Unity and KSP I do not know. I do not know if stock KSP fairing would allow joints and deformation. If not then it would have to be a separated part and scale copied from the frame, or you might come up with a alternative. On my end every joint is scaled separately on 2 axis, plus the two ends its a total of 12 value to control. To get a nicer shape it would require more edge loop, so a auto scale would be nice.

There is a alternative that would be much simplier to control. Its based on bezier curve, the curve is the shape of the frame and fairing, leading angle of the two end cap act as  bezier handle angle, that leave only one value per cap to control the shape. So, in KSP, say you have 3 part, you have the middle frame and a variety of ends caps with different shape and different leading edge to chose from. You set your frame length and select your cap size, the frame bar and fairing auto adjust to a default weight on both Bezier handle. Basicly you have a soft and progressive blending. If you reduce the bezier handle lenght of the front cap it will make the front curve sharper while leaving the curve from the bottom cap relatively intact. Reduce both bezier handle lenght to zero and faring and frame with be straight. Now, you do not have to generate a mesh using these curve, (does Unity support nurbs?) You can use this on top of the joint scaling system by sampling the curve at regular distance and use that value to scale your joints...

I hope I was clear enough. Its a "simple" idea and it might be much more complex to put in practice.

Share this post


Link to post
Share on other sites

Good shots of ISS on this... 

 

Share this post


Link to post
Share on other sites

@RedParadize


Thanks for the mock up and suggestions.  I'll give what you've presented a bit of thought, might be able to get some of it working.  I've never had much luck with skinned meshes, but have learned a bit recently, so not sure if I would even be able to get the basics of it working.  Unity has no built in support for curves, nurbs, bezier, or otherwise; so whatever is done it will have to be a pre-built mesh that is manipulated at runtime.  There will not be any scaling or modularity on the 'frame' parts, so the aeroshell really only needs to support a single size (however it needs to be configurable depending on how the user has designed the craft -- what parts, in what order/setup).
 

 

There are still the KSP-specific problems that would need to be solved first though.  How to properly set up the shielding and occlusion for the parts?  Doable for a 'full' aeroshell, but I can't think of a way to make it work once half of it is discarded (most images show the top half of the aero-shell being discarded prior to or partway through the re-entry).  There is also the problem of how to position the cut-outs properly for the engines for 'random' craft designs (might be doable using bones, but as stated I've never had much luck with skinned meshes).

Share this post


Link to post
Share on other sites
On 2/26/2017 at 9:38 AM, Shadowmage said:

Noted, and updated.  Sadly yeah, that stuff was broken and removed in the 1.05->1.1.x updates (when all of the wheels broke).

Hoping to start working on a refresh of those parts and the entire LanderCore system before too long.

That will be awesome! Thanks again for the awesome mod. Definitely my favorite. 

 

Still looking for a good Dragon v2 pod though... any chance you are planning on making some SpaceX parts? 

Share this post


Link to post
Share on other sites

Re: areoshells - I don't think skinned mesh renderers work for colliders.  So if that option were pursued you would have to accept them not colliding with anything.

Share this post


Link to post
Share on other sites
1 hour ago, Shadowmage said:

@RedParadize


Thanks for the mock up and suggestions.  I'll give what you've presented a bit of thought, might be able to get some of it working.  I've never had much luck with skinned meshes, but have learned a bit recently, so not sure if I would even be able to get the basics of it working.  Unity has no built in support for curves, nurbs, bezier, or otherwise; so whatever is done it will have to be a pre-built mesh that is manipulated at runtime.  There will not be any scaling or modularity on the 'frame' parts, so the aeroshell really only needs to support a single size (however it needs to be configurable depending on how the user has designed the craft -- what parts, in what order/setup).
 

 

There are still the KSP-specific problems that would need to be solved first though.  How to properly set up the shielding and occlusion for the parts?  Doable for a 'full' aeroshell, but I can't think of a way to make it work once half of it is discarded (most images show the top half of the aero-shell being discarded prior to or partway through the re-entry).  There is also the problem of how to position the cut-outs properly for the engines for 'random' craft designs (might be doable using bones, but as stated I've never had much luck with skinned meshes).

 

I can help you with skinning if you want. Its not complicated at all. Last time I played with unity (6 years ago?) there was some issue with skinning, but these problem does not matter given influence will be 100% or 0%. There was also some problem with scaling joints hierarchy, that would be a problem only if you decided to have doors on fairing. But there is way around that. As for bezier curve, they do not need to get into Unity, there only serve as a mathematical formula to calculate scaling of each cross section. I am not that great in math and programming, but I am convince that if I do you a graph of the logic behind it you will pick it up quite easily.

 

As for how it would be handled in KSP, thats where the "divide in conquer" come into play. It will not solve every problem. First off, in the basic concept, every animated bay and maybe engines placement would be located in end cap so shielding and occlusion would handled using stock or existing SSTU stuff. As for what's inside fairing section. I see two option. The first one would be to have two modified "box" SSTUAirstreamShield, one for the top fairing and one for the bottom. Simple enough, If you discard the top fairing, then everything contained into it would create drag but should still be shielded from heat since the bottom still create occlusion. Its not perfect but it should work. The other option would be to have a 3 state variant of your SSTUAirstreamShield. 1: Fully protected, no drag is produced. Solar panel and engine don't work.  2: One panel is discarded then everything work, but everything is still protected and create no drag. 3: two panel are discarded, nothing is protected.

 

This only cover for cap and frame/faring. So 1 part if frame/faring section is merged with end cap like it is for your tanks. 3 part if caps are separated or if fairing are part themselves. 5 parts if both fairings and caps are separated. I might do some 2d graph later on if you are interested. If its not the way you want to go its all good, I had fun thinking about this.

 

@blowfish

I trough about this issue as well. The only skinned part that absolutely need colliders is the frame itself, carefully choosing frame shape could allow a unskinned collider to match only trough translation and scaling, same for potential cross section.
 

Edited by RedParadize

Share this post


Link to post
Share on other sites

Made a Jupiter-246 just now. Nice.

Share this post


Link to post
Share on other sites
On 2/28/2017 at 8:17 AM, Shadowmage said:

 

Yeah, still a little ways out (month or two before I can start working on it), but it is the next planned 'big thing' to do. 

Probably safe to start the discussions and planning on it.  Going to be two main lines of 'landers'.  Vertical (the stuff that is available now, with some minor reworking), and Horizontal (all new stuff).

The first is the classic vertical lander setup, much as is available now.  Will include the current LC pods (perhaps updated a bit), and a new set of octagonal MFT fuel tanks.  The new tanks will -not- include solar, rtg, legs, etc; the old system for those was a giant collection of hacks, and I have no desire to go down that road again.  Instead I am working on a system of 'pre-built' leg sets that will ship with KF.  The new tanks will likely also be less of a 'bare tank' look and more of an enclosed fuel tank segment; makes it far easier to allow for the length/model adjustments used by the MFT module (still undecided on this, might be able to get bare tanks working).  When the tanks are created I'll also work on creating some octagonal mounts and adapters for them.  One final bit that I'm going to investigate is allowing for standard rigid/animated landing leg setups to be included in the tanks (probably as one of the adapter/end-cap types); these legs, if included, would feature no suspension functions and would be driven to deployment by a standard animation  (WIP support for this kind of a setups is in place for the cargo-bay modules, can likely back-port it to be usable on the MFT modules -- which would also allow for MFT nosecones/adapters that had built in service bays and the like, and possibly other uses not yet considered).

 

The second line of lander parts will be designed for horizontal lander creation.  It will likely be a bit of a mashup between several existing reference designs, and my old SC-C design:
0110b.jpg338b4ff1c5e6a61ae8551a312cddc1d2.jpg

Yqaupgv.pngPZsLOYw.png

Horizontal lander, with either squashed octagonal or hexagonal main form factor.  Will include segments with built in legs and/or engines/rcs, cargo bay segments, frame-bays, fuel segments, etc.  These parts will likely not include any form of scaling/MFT support, and will be less of a generically usable system.  Still a bit undecided on these -- would like for them to have a wider range of compatibility with other mods, but I'm unaware of any other mods using similar form-factors for fuselage parts.

 

@Angel-125 is also giving this idea some thought in the DSEV part of his empire. 

7zlZ67a.png

Share this post


Link to post
Share on other sites

Also: 

@PART[SSTU-ST-HAB-A1|SSTU-ST-HAB-A2]:NEEDS[SSTU&ExtraplanetaryLaunchpads]
{
    MODULE
    {
        name = ExWorkshop
        ProductivityFactor = 1
    }
}


@PART[SSTU-ST-HAB-B1|SSTU-ST-HAB-B2|SSTU-ST-HAB-B3|SSTU-ST-HAB-B4]:NEEDS[SSTU&ExtraplanetaryLaunchpads]
{
    MODULE
    {
        name = ExWorkshop
        ProductivityFactor = 1.5
    }
}


@PART[SSTU-ST-HAB-C1|SSTU-ST-HAB-C2|SSTU-ST-HAB-C3|SSTU-ST-HAB-C4]:NEEDS[SSTU&ExtraplanetaryLaunchpads]
{
    MODULE
    {
        name = ExWorkshop
        ProductivityFactor = 2
    }
}

 

Share this post


Link to post
Share on other sites
18 hours ago, Sudragon said:

Also: 

[EL workshop patches]

Thanks, I'll certainly see about including some EL configs as I keep working on the mod-integration patches.  Not quite sure how I want to balance it all quite yet, still need to play around a bit more with MKS/EPL to see how it all works in the newest versions.

 

Nothing too new in the SSTU development front recently, but did have a few pics to share :)

Slowly making progress in my career testing game, and finally finished building (using EPL - in space) the mothership for the upcoming Duna mission.  ~415t wet, ~215t dry, 9x NRV engines running LH2 (800isp), ~5100dV at current configuration (has room for more supplies).  Should have about 10y worth of supplies and ~8y worth of hab-time using USI-LS (for a crew of 4).  Includes science-lab (stock) and Agroponics unit (USI), and carries a small lander.  Intended to be fully re-usable it performs propulsive capture both at destination, and upon return to Kerbin.

Has insanely large fuel tanks due to using real density for LH2, which is apparently absurdly light.  It could pack quite a bit more dV, but the tanks quickly grow to unmanageable sizes.  Chemical engines can provide the same dV at 1/4 the size, but at nearly 3x the mass in fuel.

Aifqcbq.png

Carries a re-usable single-stage 3-crew Duna lander based on the SC-B-CMX pod with a SuperDraco-L engine mounted in the center of four fuel tanks that double as landing legs.  Includes enough parachutes for a low-velocity engine assisted landing, and enough fuel for de-orbit from and ascent to low orbit from near-equatorial sites.  Mothership carries enough fuel for 3-4 additional landings and spare RCS fuel.

P31aFf1.png

Was fueled after construction by four launches of a single-stage, recoverable, LH2 fuel tanker.  ~50t payload capacity, using four F-1 engines.

5OoQZXC.png

Share this post


Link to post
Share on other sites
12 minutes ago, Shadowmage said:

Nothing too new in the SSTU development front recently, but did have a few pics to share :)

Playing is fun, isn't it? Especially with your parts in the mix. But, if you cannot enjoy your own work, then why do it to begin with?

Share this post


Link to post
Share on other sites
1 hour ago, Shadowmage said:

Slowly making progress in my career testing game, and finally finished building (using EPL - in space) the mothership for the upcoming Duna mission.  ~415t wet, ~215t dry, 9x NRV engines running LH2 (800isp), ~5100dV at current configuration (has room for more supplies).  Should have about 10y worth of supplies and ~8y worth of hab-time using USI-LS (for a crew of 4).  Includes science-lab (stock) and Agroponics unit (USI), and carries a small lander.  Intended to be fully re-usable it performs propulsive capture both at destination, and upon return to Kerbin.

Has insanely large fuel tanks due to using real density for LH2, which is apparently absurdly light.  It could pack quite a bit more dV, but the tanks quickly grow to unmanageable sizes.  Chemical engines can provide the same dV at 1/4 the size, but at nearly 3x the mass in fuel.

What's the TWR on that thing? Seems like it'd be pretty low. Anything below ~0.60 gets annoying for me. Having to figure do multiple burns to get out of LKO (or any other body for the return trip) is not something that i find enjoyable

Share this post


Link to post
Share on other sites
4 hours ago, Shadowmage said:

Thanks, I'll certainly see about including some EL configs as I keep working on the mod-integration patches.  Not quite sure how I want to balance it all quite yet, still need to play around a bit more with MKS/EPL to see how it all works in the newest versions.

 

Thanks. I was trying to get this:

3mBjh2y.png

to work and discovered that the inflatables aren't rigged for EL, even if @JoseEduardo had rigged them MOLE style.

Share this post


Link to post
Share on other sites

@Shadowmage I am loving SSTU and have been playing around with re-creating lifters to share with the community since the ones linked in the OP are no longer shared.

Is there a specific scale that you have modeled everything after? I know that most of the parts seem to be in about the 65% of full size, but then there are others that do not fall into that category. For example, the RS-68 for the Delta IV is at 3.75m while in RL it is 5.1m for a 64% of full size.

Thanks!

Share this post


Link to post
Share on other sites
45 minutes ago, pap1723 said:

@Shadowmage I am loving SSTU and have been playing around with re-creating lifters to share with the community since the ones linked in the OP are no longer shared.

Is there a specific scale that you have modeled everything after? I know that most of the parts seem to be in about the 65% of full size, but then there are others that do not fall into that category. For example, the RS-68 for the Delta IV is at 3.75m while in RL it is 5.1m for a 64% of full size.

Thanks!

Generally 64% scale, or the closest stock stack size.  E.G. Orion is ~5m real life, which would be 3.2m at 64%, but the closest stock stack size is is 3.75, so went with that instead. 

Same thing with the RS-68.  Although I think the engine is closer to 64% scale, the shroud is likely a bit off as it needed to work with the stock stack-sizes.  Real life bell diameter = ~2.43m, scaled diameter = ~1.612m, actual scale = ~66%.

Share this post


Link to post
Share on other sites

about Orion, I included a cloned version of it at ~64% scale (3.125m) at SSTU-expansion.

It's cloned, so it doesn't remove the original 3.75m Orion :P

Share this post


Link to post
Share on other sites
5 minutes ago, JoseEduardo said:

about Orion, I included a cloned version of it at ~64% scale (3.125m) at SSTU-expansion.

It's cloned, so it doesn't remove the original 3.75m Orion :P

I did exacly the same. It looks better, specialy when docked with a lander. I also have a soyuz at 1.875 with fairing at 2.5.

Share this post


Link to post
Share on other sites
12 hours ago, StickyScissors said:

What's the TWR on that thing? Seems like it'd be pretty low. Anything below ~0.60 gets annoying for me. Having to figure do multiple burns to get out of LKO (or any other body for the return trip) is not something that i find enjoyable

Low... I think it runs from 0.15(full)-0.25(empty).  Which is still about double what the SC-C-SM puts out (~0.07TWR), and I use it all the time.  Yes, the ejection and capture burns will be ~15m each.  No problem, just start from a 300-500km orbit, turn on physics-warp, and go get a drink or something.  I've never had to split up my burns, just need to leave from a higher orbit.

Even did a ~5km/s capture at Moho using an Ion probe with only 0.05TWR.  Had to start the capture burn as soon as it entered Moho SOI, and burn continued quite a bit past the initial PE.  Just takes some creativity and planning to use low-twr/high-efficiency setups. 

Share this post


Link to post
Share on other sites

Idk about all that smart maneuvering, I just put a bunch of vac super dracos on my ships :D

Share this post


Link to post
Share on other sites
1 hour ago, Shadowmage said:

Low... I think it runs from 0.15(full)-0.25(empty).  Which is still about double what the SC-C-SM puts out (~0.07TWR), and I use it all the time.  Yes, the ejection and capture burns will be ~15m each.  No problem, just start from a 300-500km orbit, turn on physics-warp, and go get a drink or something.  I've never had to split up my burns, just need to leave from a higher orbit.

Even did a ~5km/s capture at Moho using an Ion probe with only 0.05TWR.  Had to start the capture burn as soon as it entered Moho SOI, and burn continued quite a bit past the initial PE.  Just takes some creativity and planning to use low-twr/high-efficiency setups. 

I can't stand low TWR. I raised trust on most service module just because I am not that patient... 15m burn are killing me. I wish Persistent trust mod would be more polish and work on with stock maneuver node, without it I just can't use most of Nertha engines.

Share this post


Link to post
Share on other sites
6 hours ago, Shadowmage said:

Low... I think it runs from 0.15(full)-0.25(empty).  Which is still about double what the SC-C-SM puts out (~0.07TWR), and I use it all the time.  Yes, the ejection and capture burns will be ~15m each.  No problem, just start from a 300-500km orbit, turn on physics-warp, and go get a drink or something.  I've never had to split up my burns, just need to leave from a higher orbit.

Even did a ~5km/s capture at Moho using an Ion probe with only 0.05TWR.  Had to start the capture burn as soon as it entered Moho SOI, and burn continued quite a bit past the initial PE.  Just takes some creativity and planning to use low-twr/high-efficiency setups. 

That..has turned out to be some pretty good advice. And it has lead to the most recent (read: 20th) iteration of my Reusable Nuclear Shuttle.

TWR: 0.23*

DV: 7370*

Mass: 185 Tons*

*specs may vary depending on configuration

bIPdZeF.png

-

Perhaps the (hopeful) finalization of RNS will allow me to restart the recently re-discovered Project Big Giant Fuel Station... The station itself being refueled by an RNS moving fuel from LMO to LKO via a fuel mining/refining setup...of which is waiting on lander parts :P

yX1D49D.png

-

And some other random shots from my career game, being used to subside my anxiousness for the return of the lander stuff and switch over to 1.2.

2EZJbtG.png

xlEvpzt.png

Edited by StickyScissors

Share this post


Link to post
Share on other sites
Just now, RedParadize said:

@StickyScissors Are these old picture? The part in the first picture have been textured quite a while ago.

Taken in the past few days, but i havent updated to 1.2 yet. Still trying to find time when i can wake up during the "off-peak" hours of my internet provider and download all my mods for 1.2. I would just download them all outright, but my daytime data is limited, and i don't want to waste it on mods

Share this post


Link to post
Share on other sites

While working through fixing a problem with KSPWheels last night, I hit upon a solution for one of SSTU's longest-standing annoyance issues -- the 'can't surface attach an SRB or MFT until it is dropped and picked up again' problem.

To make a long story short -- it was a problem with layers -- KSP manipulates layers of parts in the editor to allow for raycasting against only the 'active' parts of a craft, any parts unattached to the craft should be set to layer 1, parts on the craft set to layer zero.  My modular part code was cloning new models and adding them to the part, using the default layer (zero), and thus the newly cloned parts were intercepting the raycasts that should have detected the surface attach positioning.

Yay for progress -- glad that SSTU is getting something useful out of all the work I've been putting into KSPWheel (even if it is just a bugfix).

 

Share this post


Link to post
Share on other sites

Hey Shadowmage, are you still looking for a modeler for the IVA's ? I'm having a lot of fun with SSTU's parts and I really can't wait to have cool interiors for those inflatable modules. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.