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

[Jimbodiah]

@tater   Try Kerbal Foundries, there are some scalable legs there. You might know the guy that picked up that mod   

@Shadowmage  You make the rest of the parts look like the lego movie now, and might have spoiled us all for the future. And congratulations on the 100th release on GitHub, by the way

Edited October 24, 2017 by Jimbodiah

[Shadowmage]

@RedParadize

Yeah, the tank that was in the PBR testing pack was pretty early in the modeling cycle.  I've since added.. lots of stuff   No electrical, but there are fuel lines running from all of the tanks, and completely through the part.  Also some bracing bits tying the tanks / frame / fuel lines together nicely.

Small selection of the available variants/setups.  Not shown are the multiple tank lengths, and many more variations will be possible.  Pretty much finished with the geometry at this point; looking things over for errors and starting to figure out the UV and AO arrangements.  Going to be... fun... putting it all together.

 

 

[vossiewulf]

14 hours ago, Shadowmage said:

The limitation in KSP is that you cannot move other parts or any attach nodes with an animation, you can only animate the mesh of the part.  About the only option for a probe-carrier is to add decouplers with 0 force.

If you did want to model such a part, please keep in mind that the PartModule that runs the system expects the models to be constructed in a specific fashion.  Each 'length' of the modular part needs to be its own distinct model / mesh, and the plugin switches between these prebuilt models at run-time.  So from a modeling perspective it is best to build the base model in a modular fashion -- one end piece that is mirrored for the other end, and one central piece that can be duplicated to extend the length (that is all you would need to model/texture; from there I would do the duplication/etc to create the unique lengths).  This is the setup I use as it allows the end-pieces to have a different AO setup from the repeated middle section, while still allowing for re-use of both the end and middle sections, all while keeping texture size down to a minimum.

A 1x length part would be setup like: End - Middle - End
A 2x length part would be setup like: End - Middle - Middle - End
A 3x length part would be setup like: End - Middle - Middle - Middle - End

Really though anything will work as long as each 'length' of the part has its own model.  Technically you could even export just the 'pieces' and recomposite them through config (e.g. you export just the end and middle, and put them together to form the finished model through the equivalent of MODEL nodes); might actually be easier from a modeling program/Unity perspective as there are fewer models to deal with.  Hmm... could actually reduce memory use (both distro size and RAM use) a tiny bit by doing that as well...

 

Thanks. That's how I was anticipating building it based upon looking at what your tanks/parts do. Clearly it has a conception of zones that have independent meshes and logic that tells it what order to put the zones into for each length. I assume the length of each slice/zone whatever we call them is arbitrary but recommended to be no shorter than .5m? I'm thinking at least 1m should be standard here and maybe 2m, since we want to put attach nodes along the truss to make it an intermodal cargo carrier too, the lengths of the middle slices have to be equal to the length of the smallest cargo section and I don't think we want 1m cargo sections but I'll look at it.

[Shadowmage]

6 hours ago, vossiewulf said:

Thanks. That's how I was anticipating building it based upon looking at what your tanks/parts do. Clearly it has a conception of zones that have independent meshes and logic that tells it what order to put the zones into for each length. I assume the length of each slice/zone whatever we call them is arbitrary but recommended to be no shorter than .5m? I'm thinking at least 1m should be standard here and maybe 2m, since we want to put attach nodes along the truss to make it an intermodal cargo carrier too, the lengths of the middle slices have to be equal to the length of the smallest cargo section and I don't think we want 1m cargo sections but I'll look at it.

Pretty much, yeah.  Should also add that I model all of the modular parts (tanks/trusses/adapters/etc) at a 5m model scale and as close to 128pixels-per-meter linear texture scale as possible.  The actual model scale is personal preference, as long as the texture scale is kept to the same scaling (e.g. if modeled at 2.5m, the texture needs to be ~256px/meter; at 1m the texture would need to be ~640px/meter).  This is all done to keep the textures reasonably detailed on the large parts, and not overly detailed when they are scaled down in size.

At 5m scale, I would imagine that you would want segments of either 2.5m or 5m length.  Shorter than that and it ends up being too many models to export, much longer than that and the sizing isn't granular enough.  Might be that you have a 1m end-cap mesh on both ends, but make the repeatable segment 2.5m or 5m in length, so the final part ends up being in 2.5m increments with a +2m offset -- 4.5m, 7m, 9.5m, etc.  Trying to figure out the way to keep the geometry modular is part of the fun of modeling these parts (I often spend more time thinking on how to put the models together than actually modeling the stuff....).

 

[RedParadize]

Hi @Shadowmage 

In my last play trough couple weeks ago, I noticed a bug when using your tank (any kind).

When stacked right next to a in line cargo bay, it prevent it to shield stuff when closed. I also get a drag miscalculation when using your tank with regular module, when sstu tanks are on top its like if they only partially shield the bottom part. If I understand correctly it have to do with tanks bulkheadProfiles not matching cargo and other part size. Because of that, reentering a rocket become very difficult and accurate landing is impossible.

If I finish working early, I will try do reproduce this in your latest build.

 

[Shadowmage]

A bit of a peek at the modeling process -- this is the LC fuel tanks 'unique geometry' - the bits that all need to be UV unwrapped and grouped into texture sheets; 40 unique meshes/objects.  This little bit of geometry will be mirrored/duplicated in various fashions to create the full fuel tanks.  All of these objects will be 'joined' into a single mesh for the purposes of generating the UV layout on a single texture sheet.

Meshes:

After it gets unwrapped will start the AO baking process -- the unwrapped meshes will be split back into individual objects, mirrored and duplicated, and the models pieces put together into their semi-final layouts / grouped for each AO texture bake.  Often the objects are left separate during AO baking, baking one object at a time and adding it all cumulatively onto a single AO map. 

Combined UVs (consistent UV scale across all faces).  This sheet will be broken up further into 3/4 separate sheets for each group of geometry based upon how many AO bakes that group of geometry will need.

 

Once baking is complete and AO textures verified the process of building the actual exportable models begins -- again duplicating/mirroring meshes, but this time into their final arrangement.  Objects are grouped/joined as much as possible to reduce draw-calls / minimize the number of meshes in the part.

Baking is currently underway -- quite a long process for high-res textures -- mostly just waiting while the CPU crunches on the raycasting.  Might be able to start work on configs and/or texturing this evening while the baking finishes.  Currently at 1.5hrs of baking time so far, and only have the 'with-center-tank' variant nearly done.

[Jimbodiah]

I hope you disabled core parking on your PC, a nice standard feature of Windows that shuts down half your cpu cores to save energy?

[Shadowmage]

28 minutes ago, Jimbodiah said:

I hope you disabled core parking on your PC, a nice standard feature of Windows that shuts down half your cpu cores to save energy?

While that might be a concern for some... I'm a long-time techie.  I know right where my cores are running when I put them under load (--4.5ghz, <55c with 4 cores fully loaded).  Certainly a good thing to keep in mind when setting up a new Windows installation though.

Spoiler

My home comp, hand built bench-rack/case, full custom build as far as components go.   Full custom water cooled setup with 2x360mm radiators, single loop shared between CPU and GPU.

This was awhile back when I only had 8g of ram in it.  During the winter while I'm gaming we can use the radiators to heat the computer room (and probably half the house...), during the summer... it can get uncomfortable in the gaming room   Some of the components are getting a bit old at this point, but it is still holding up rather well (Sandy Bridge i5-2500k is probably the oldest bit, but still capable).

The problems I was encountering were using my work computer for the initial bakes (~4x3.4ghz i5), and baking things with mirror-modifiers enabled rather than manually selecting the geometry post-mirror-application (it also bakes the mirrored meshes, so up to 8x longer for full x,y,z mirroring).  I was also baking at 4x native resolution, which increases the time needed by 4^2 (16x).  Can't cut the resolution down very well, but I think I can probably cut that time down to <5min per sheet by doing some manual geometry selection; takes a bit longer in the manual setup phase, but far less than 8x.

Hopefully will finish up the bakes tonight, and start working on the model setup for export/configs/texturing 'soon'.

 

[vossiewulf]

3 hours ago, Shadowmage said:

While that might be a concern for some... I'm a long-time techie.  I know right where my cores are running when I put them under load (--4.5ghz, <55c with 4 cores fully loaded).  Certainly a good thing to keep in mind when setting up a new Windows installation though.

My last desktop that was i7-5820 with water cooling etc. etc. that I overclocked from 3.7 to 4.2Ghz was stable everywhere, including Intel's own CPU stress test, except for the Corona renderer that is pure CPU. Very nice renderer but turns out it's the most brutal CPU stress test in existence, so if you want an acid test of overclocked CPU stability, download their trial. On the up side my machine had the #1 top speed rendering their test scene at the time.

Edited October 25, 2017 by vossiewulf

[vossiewulf]

3 hours ago, Shadowmage said:

The problems I was encountering were using my work computer for the initial bakes (~4x3.4ghz i5), and baking things with mirror-modifiers enabled rather than manually selecting the geometry post-mirror-application (it also bakes the mirrored meshes, so up to 8x longer for full x,y,z mirroring).  I was also baking at 4x native resolution, which increases the time needed by 4^2 (16x).  Can't cut the resolution down very well, but I think I can probably cut that time down to <5min per sheet by doing some manual geometry selection; takes a bit longer in the manual setup phase, but far less than 8x.

Hopefully will finish up the bakes tonight, and start working on the model setup for export/configs/texturing 'soon'.

Are you using SP for the baking? When I was doing a test recently for the vent parts, it took seconds to do the required textures at 2k, including AO. Yes you have more polys but like a few multiples, not thousands more, the UVW map shows straightforward simple meshes.

[Jimbodiah]

You'd be amazed how many people have high-end systems and do not know to disable core parking, only to end up with an i7 running at i5 specs because windows (7 at least) deems it necessary to block all the hyperthreading cores as a default.

I'm turning into an old geezer now; quiet is the new oc

[Shadowmage]

7 hours ago, vossiewulf said:

Are you using SP for the baking? When I was doing a test recently for the vent parts, it took seconds to do the required textures at 2k, including AO. Yes you have more polys but like a few multiples, not thousands more, the UVW map shows straightforward simple meshes.

I'm using blender for the AO bakes -- due to how these parts are split up, there is no way I could do all of the separate bakes in SP.  The same base geometry is being used in 6-10 different configurations, each with their own AO needed.  (and yes, I do all my models directly in 'low poly' -- I'm not even sure how to make a 'high poly' model, all of my modeling work has been focused on simple game-ready models where creating a high-poly version seemed wasteful)

After I stopped it from baking mirrored duplicates, Blender was far faster at the bakes -- closer to 1-2 minutes per sheet.  I'm kind of curious as to what algorithm/setup SP uses for its bakes, as they are extremely fast given the size and raw number of bakes that it does.  I know that Blender uses Quantized Monte Carlo ray-casting on the CPU -- kind of seems that SP is either using approximated bakes (non-raycasted, but much faster), or it is somehow doing it on the GPU (GPU raycasting = ???).  Or maybe Blender is just slow

 

Got the initial couple of the finished models exported and run through PartTools last night, and configs created far enough to test the overall geometry in game.  Overall I'm pleased with how the tanks compare versus the old ones as far as geometry layout and sizing -- the new tanks offer quite a few more options than were previously available.  A lot more options.  Especially with the inclusion of the 'single-inset' and 'double-inset' variants -- many previously hard to build rockets will be much cleaner to put together (without resorting to excessive clipping or tank stacking).  Found one mesh/geometry problem that will have to be solved in one fashion or another -- when using the zero-length body, some of the bracing joint meshes from the adapters clip into each-other resulting in z-fighting; fairly certain I'll have to do some minor skewing on the geometry to fix the clipping -- not many other options are available given the mirrored setup and UV layout (thankfully I had only set up 7 adapter models, so only need to fix that many; any new models that are setup would use the fixed geometry from the start).

[CatastrophicFailure]

6 hours ago, Jimbodiah said:

You'd be amazed how many people have high-end systems and do not know to disable core parking, only to end up with an i7 running at i5 specs because windows (7 at least) deems it necessary to block all the hyperthreading cores as a default.

I'm turning into an old geezer now; quiet is the new oc

 

Pardon the segue, been a bit lost in the jargon following this ever since it switched from rockets to cooking. Anyways, details on this plz?

[Nightside]

1 hour ago, CatastrophicFailure said:

 

Pardon the segue, been a bit lost in the jargon following this ever since it switched from rockets to cooking. Anyways, details on this plz?

I had to look it up. Basically how to make a 2D thing look like a 3D thing. Apparently it needs a lot of computer juice.

UV mapping stands for the technique used to "wrap" a 2D image texture onto a 3D mesh. "U" and "V" are the names of the axes of a plane, since "X", "Y" and "Z" are used for the coordinates in the 3D space.  

Ambient Occlusion baking is the act of rendering the global occlusion of an object, to a texture, via its UV coordinates, This means your object must be completely unwrapped before you can attempt baking AO.

[CatastrophicFailure]

17 minutes ago, Nightside said:

Ambient Occlusion baking is the act of rendering the global occlusion of an object, to a texture, via its UV coordinates, This means your object must be completely unwrapped before you can attempt baking AO

Darn. I was hoping at some point there would be cookies. 

[Nightside]

From what it sounds like @Shadowmage should be able to bake some on his computer while it works, or at least fry an egg...  Put that waste heat to work!

[vossiewulf]

Ambient Occlusion maps basically show how much light a given point can "see". A point in a recessed corner is simply going to receive much less light than a point on the outside corner of a cube that can "see" almost the whole world around it. It is a grayscale map where white can see everything and progressive shades of darker gray are used to indicate reduced access to light. It's used by procedural texturing systems like Substance Painter to know where certain effects go, like dust should accumulate in recesses and none should be on high points, and SP can tell from the AO map which is which. It can also be "burned" into the texture map to provide excellent basic shadows.

"Baking" is creating various types of model maps that will be used for various purposes - curvature maps, materialID maps, ambient occlusion, etc. - each one creates a new 2d view of the model with each point being assessed values based on the parameters the map is looking at, like material ID checks to see which material (texture) is assigned to each point. Most important is the Normal map, which refers to vectors, not how weird it is. Each triangular face in a model is defined by four data points - the x,y location of each point of the triangle plus a vector normal showing which direction that face is well, facing.

What we do now in modeling, particularly for high end effects in movies and games, is to create two versions of each model. One is extremely detailed with a zillion polygons, much more geometry than you'd ever be able to render in real time, and a low-poly version which is limited to how much you can render and which has much simplified geometry.

A normal map baker will compare those two models and then create a normal map that tells a renderer how to cheat and make the low-poly version look almost exactly like the high-poly version by having the renderer itself use the vector normal data to alter the rendering so it looks like it has all the details that were eliminated in the low poly model. This is how we are able to do all those amazing movie and game effects, we are cheating to make everything look much more detailed than the underlying geometry really is.

This is my Raven high poly model.

This is the low-poly that is actually used in-game.

This is the low poly wearing only its normal map, notice that it looks like all the detail from the high poly has been added back. There are four colors that correspond to up/down/left/right, the blend of which tells the renderer how to bend the rendering so it looks like the high poly is there. 

Here's a normal map in 2d mode, the four color facing thing should be clearer now. The purple color is an equal mix of all four colors, and says this area is flat, no differences between the two models. Any other shade says the underlying geometry is facing in a given direction even though the low-poly model has nothing there.

This is a material ID map that just shows what material is assigned where.

And this is it wearing the normal map (details still there) + the ambient occlusion map, so now it looks like it has basic shadows and the details are even clearer.

This is a curvature map. Gray is flat, white is convex curve, black is concave curve. Since this object is a machine so most of the edges are 90 degrees. It's mostly used by procedural materials that add edge-wear effects like faded paint and chips on edges.

And this is what it looks like when you combine your texture painting with all of the other maps.

 

 

 

 

 

Edited October 25, 2017 by vossiewulf

[T-10a]

How would I patch the parachute modules for the command pods/docking ports in ModuleManager to use RealChute chutes instead of the stock parachute module?

[Shadowmage]

23 minutes ago, T-10a said:

How would I patch the parachute modules for the command pods/docking ports in ModuleManager to use RealChute chutes instead of the stock parachute module?

AFAIK you cannot.  The best you can do is remove the SSTU parachute module from the parts and provide your own solution through adding more stand-alone parachute parts to the craft.

• SSTU's parachutes models are added to the part at runtime by plugin code.  SSTU uses runtime-defined animations in order to drive the deployment/inflation (model has no animations).
• RealChute parachute models are a built-in part of the part's model (often a stand-alone part).  RealChute uses pre-compiled animations to drive the deployment/inflation (animation baked into the model).

 

Someone else with more experience with RealChute might be able to provide more insight or alternative solutions.  I've never personally used it, and the above statements are based on reading through the source-code.  Your best bet might be to ask in the RealChutes thread with a question such as 'How do I add RealChute parachutes to an existing part?'.

Edit:  You might also take a look at the RO configs to see how they handled it.  I'm unsure if they somehow adapted the SSTU parts to use RC or some other solution.

Edited October 25, 2017 by Shadowmage

[T-10a]

Gotcha. I'll ask over there.

[Shadowmage]

As I'm nearing the point of an actual usable PBR release -- what feature set would be needed from a 'stand-alone' release of the shader pack?

I'm thinking, at the minimum, it will need:

• Ability to load the proper shader/asset-bundle for the current platform
  • From examination of Eve/Scatterer setup -- it might be possible to pack shaders into a single 'universal' bundle that can be loaded on any platform.
• Ability to load the shaders in a method that they might be found by external plugin code (GameDatabase.loadedShaders list)
• Ability to update the texture and shader assignments for basic parts -- update the root models in GameDatabase.loadedModels before they are used by parts.  This would be driven by config files to setup each mesh->shader->texture assignment.
• Part-Icon shader handling.  Use the list of models that have the standard shader applied to them, and apply the icon shader to the part-icons that use those models.  Will require a special StandardIcon shader variant to support the screen-space clipping functionality and adjust the lighting parameters.
• Include functionality of the ReflectionManager -- update per-vessel (or per-scene for editors) reflection probes.
• Would not include texture-switching support -- that should be provided by external mod plugin code --  SSTU already has its own texture switch, as do many other mods.  They might need to be adapted to support arbitrary texture names as the texture names used in the Standard shader differ from some of the KSP shaders, and might need to be adapted to support loading the Standard shader from the GameDatabase.loadedShaders list.  Very minor adjustments that should be simple to integrate into existing texture-switch solutions.  (see below the comments on recoloring support -- if it were included, some form of texture-switch PartModule would also be included)

Please keep in mind that this would be a 'Modding API' type release.  It is not intended to do... well... anything... by itself.  Textures and configs must be provided by the external mod that uses the API -- all it does is load the shader and apply shaders/materials/textures to models as defined in config files.  Mods that didn't need texture-switch support would not need any external plugins beyond the PBR shader API.  Mods that did want texture-switching can still implement whatever form of switching they desire in their own plugin code (or use one of the existing solutions, such as FS or B9, etc).

One thing that I'm a bit uncertain on is if I should include 'recoloring' support in the stand-alone shader/API.  As the recoloring setup requires quite a bit more plugin support (for the GUI at least), and requires at least some form of PartModule to manage persistence, I don't think it would be prudent to include it.  Also unsure as to how it could be supported in a completely stand-alone fashion -- SSTU's recoloring setup is so deeply integrated into the PartModules themselves that it couldn't be moved to an external solution very easily (and not at all in some cases).  I suppose I could release the equivalent of the SSTUTextureSwitch module -- includes only basic texture-switching and recoloring support, with no external PartModule interaction;  SSTU would still need its own built-in solution, but this would allow for others to take advantage of the recoloring setup if they desired.

I'm not even particularly sure that the shader would gain any support or use by other mods.  There have been a few very minor inquiries, but not much past that.  However I do know it won't get used much/at all unless I make it available as a stand-alone, and as that doesn't hurt its use in SSTU at all, seems like a reasonable thing to do.  Would really -love- to see some of the other mods adopt the Standard shader/PBR setup even if it is just on optional expansion packs/etc.

 

In development news:

Not much.  Spent the last couple days/nights assembling the geometry for the LC tanks.  So. Many. Models.  23 unique models so far (.mu files), and haven't even started on the paneled variants (+11 more models for paneled variants).  That is the development cost of these 'modular' parts -- lot and lots of setup time on the modeling and configs.  Still far quicker than doing each part individually, and certainly more optimal from a memory/texture use perspective (imagine if it were >140 new stand-alone models + textures for each one...).

Last count was that this single 'part' would add 145 unique part variants (unique nose-body-mount combinations), all for <10mb in textures and another mb or two in model files.  Each additional texture set will add 6mb of additional textures for the diff/nrm/metallic maps (possibly less if some bits can share textures between sets, such as the external paneling).   I intend on offering a few initial texture sets -- at least one legacy 'recolorable' set (possibly 2-3 of them), and a couple/few stand-alone non-recolorable PBR sets.  These will stick around until I can get recoloring support in the new shaders, I imagine only a couple of weeks  (who knows, I might not actually get the parts finished until the recoloring stuff is ready...).

Edit:  Quick render of all of the tank models that will be exported.  Still need to setup colliders for a few of them, but most are ready to be ran through part-tools and added to config files.

 

Edited October 26, 2017 by Shadowmage

[Temeter]

Would be awesome too see other mods use the PBR functionality as well! Of course as you say, it's hard to say how many modder would actually go for it. Seems like many like to do their own thing, but I imagine it would be hard to say no to actual reflections and shading...

23 minutes ago, Shadowmage said:

In development news:

Not much.  Spent the last couple days/nights assembling the geometry for the LC tanks.  So. Many. Models.  23 unique models so far (.mu files), and haven't even started on the paneled variants (+11 more models for paneled variants).  That is the development cost of these 'modular' parts -- lot and lots of setup time on the modeling and configs.  Still far quicker than doing each part individually, and certainly more optimal from a memory/texture use perspective (imagine if it were >140 new stand-alone models + textures for each one...).

Last count was that this single 'part' would add 145 unique part variants (unique nose-body-mount combinations), all for <10mb in textures and another mb or two in model files.  Each additional texture set will add 6mb of additional textures for the diff/nrm/metallic maps (possibly less if some bits can share textures between sets, such as the external paneling).   I intend on offering a few initial texture sets -- at least one legacy 'recolorable' set (possibly 2-3 of them), and a couple/few stand-alone non-recolorable PBR sets.  These will stick around until I can get recoloring support in the new shaders, I imagine only a couple of weeks  (who knows, I might not actually get the parts finished until the recoloring stuff is ready...).

Sounds like a crazy workload. Stay strong

Edited October 26, 2017 by Temeter

[RedParadize]

38 minutes ago, Shadowmage said:

I'm not even particularly sure that the shader would gain any support or use by other mods.  There have been a few very minor inquiries, but not much past that.  However I do know it won't get used much/at all unless I make it available as a stand-alone, and as that doesn't hurt its use in SSTU at all, seems like a reasonable thing to do.  Would really -love- to see some of the other mods adopt the Standard shader/PBR setup even if it is just on optional expansion packs/etc.

I have dreamed of that for a long time.

I think that trying to adapt your work to other texture switch plugin might be more work and maintenance than explaining how your own system.  And from my point of view the  standard shader/PBR setup is a bit like the icing on the cake. The full SSTU system, with its the tank content and scaling system, engines, model switch, texture switch... I would like to see all of that used. 

Having messed quite allot with your system (prior to texture switch) once you get how it work its not that hard. Obviously converting existing model to your system might be quite challenging.

If you would provide a exemple model, reduced to its simplest expression, with annotated config and a brief wiki for the overall architecture. Don't you think modder could quickly learn how to use its various functionality? Could they use these functionality independently? 

[RedParadize]

@Shadowmage
Regarding the quick render you did:

1-The "Boxy" variant on the left seem a bit plain. Will you add details only in texture?

2- Does it mean we wont be able to have less tank around the frame? like 2 or 4?

3- This beg for a stretchable hexagonal frame!  

[captinjoehenry]

I love this mod a ton.  The only odd thing is that once you fully upgrade the SSTU tanks they hold an insane amount even at small sizes.  Is this normal or is this caused by a bug in my install?  If it is a bug I would guess it's from module fuel tanks and the volume system being confused?