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

[vossiewulf]

By the way, you should experiment with real high poly/low poly + normal map  modeling flow, with correct environmental reflections I think the difference will be noticeable enough to do that moving forward. At the same time I doubt think the difference is a big enough improvement to consider redoing previous models.

Besides appearance improvements, going HP/LP also makes your models much more efficient, allowing you to use very few polygons in places to really cut down the overall poly count. Like if you're doing an engine that has all sorts of small lines routing the fuel and oxidizer around, your HP should use 32-sided cylinders, the LP can easily use just 6 sides or in many cases just 4 sides, and yet from anything but very close distances and certain angles, you can't tell the difference in game- both the environment and standard specular reflections on the LP will act as if the underlying geometry is a very smooth 32-sided cylinder.

The process shouldn't be creating a very high poly base model and then spending three days welding vertices on a copy to generate the LP. You'll have to experiment a bit and I suggest you look for an article or two on HP/LP modeling strategies, but as with SP, once you get it, it goes very quickly; HP/LP done correctly can be very nearly as quick as modeling just one LoD. Most concise explanation is you have to build your full model in your head first and look for places where you might get stuck welding- with a bit of thought, many of those can be eliminated or made easier. Don't get me wrong you do end up welding vertices to make the LP versions of certain elements, but you want to avoid it as much as possible as it's so slow.

Also, besides the benefits to overall rendered appearance due to everything being calculated based on HP smooth curves and lines, there's another thing I do where I really like the effect. As you know, one of the subtle features of CG that makes people go "oh that's CG" without knowing exactly why is the infinitely-sharp edges everywhere. Neither nature nor humans like sharp edges, they don't exist without specific work to make them sharp and even then they're never as sharp as a modeler makes them. Your brain notices immediately when edge reflections are missing as it relies heavily on rounded reflective edges to establish the 3d shape of things it sees. That's always bugged me, but just recently you see real attempts to address it, both SP and Mental Ray have some parameters for edge rounding now but (IMO) neither work really well yet.

What I do is after I have my HP/LP pair, I copy the HP and hide one to maintain as the original HP. Then I take my HP copy and spin through the elements and chamfer as many edges as possible, this is one place where MAX still has bugs that I remember being in their 1994 release. Hopefully that's one thing Blender does better. As long as I'm not hitting MAX bugs, this only takes maybe 15-30min on models of the complexity you're dealing with.

Then I use the chamfered-edge version as the HP when I bake the normal and other maps in SP. All of those now nicely and subtly-rounded edges will be captured correctly in the baked maps and when you render your model and see it you'll definitely make some sort of happy sound, you will notice the effect immediately.

(I just know I'll check back in three days and he'll have invented his own Blender scriptlet macro thingy, redone all his models, and will be adding that to his shader distro)

Edited November 4, 2017 by vossiewulf

[T-10a]

37 minutes ago, vossiewulf said:

~snip~

Either that, or he'll somehow work out how to git push realtime changes in his models w/ said blender addon.

[vossiewulf]

Quick bug (maybe) report, recoloring UI doesn't seem to work for the SSTU - SC-GEN - PDC - Custom Decoupler. Ok, it's just slightly possible this naming convention was created by an engineer, I especially like the dashes with or without spaces to indicate group or specific object variant. Anyway, at least I can't get recolor to change anything on that decoupler, ditto the probe core. And it seems that certain texture choices disable recoloring, like when I have the magic fuel tank set to have a gold round dome nose, I can no longer recolor that section. Not exactly a critical issue but if at some point you find yourself looking at it, a pass through all the cases looking for ones where either the recolor button shouldn't be available on the UI, or available but with some options grayed out, would probably be a useful UI consistency activity.

[Shadowmage]

Spent a bit of time yesterday playing  with Substance Designer, created a (crude) radial heat-shield material and a 'space tape' material for the Apollo CM.  Bit more cleanup to do, finishing off the RCS ports, adding some slight dust/noise to the entire thing, and doing the details on the inside of the parachute cap.  Not fully satisfied with the heat shield texture, but it is about as close as I can get it without crazy texture resolutions.

Unfortunately looks like I won't have the PBR texture testing pack until next weekend; still quite a bit of work to do to finish up the rest of the Apollo/Saturn parts.  I was going to do just some quick conversions on them, but figured that if I'm going to spend time working on them I had better do them properly or at least make sure what I do can contribute to the finished textures.

Also realized that there is a fairly easy way for me to convert the existing 'recolorable' textures to use the PBR setup by simply adding in some metallic maps (and/or metallic slider to the GUI).  The existing textures are already setup in a 'base color' + 'roughness' + 'occlusion' type setup; all it would take would be to add in the metallic channel to the specular maps (which are really roughness maps), and then all of the existing recoloring setups could be converted quite easily.

 

[Shadowmage]

Indeed, even just the existing recolorable textures with an added metallic map can show quite an improvement in shading compared to the legacy shaders.  All that I've done on these examples was to add a metallic-map to the existing specular textures, and do pretty much a direct port of the recoloring shader to use the Standard shader lighting functions.

Not much difference in the painted textures.  The fuel line is marked metallic, everything else as non-metallic.

(not shown are the orange foam, but there will be little/no difference on those)

It is the silver and gold (metallic) textures where the largest differences will be seen.  Even with the simplistic textures these take on much more realistic look.

Even the existing gold-foil texture looks much better with the new lighting.

The good news from all of this is that yes, there will be some form of recoloring available for parts that use the new shaders.  All it takes is a adding a metallic mask to the alpha channel in the existing specular textures, and a small patch to switch to the new shader.  The textures will likely be changed in-place (so the default-shipping textures will include the metallic masks), while the shaders will be swapped over with the rest of the SSTU-PBR expansion pack.  These would be separate from any additional new PBR/more realistic textures that I create for parts, which will likely not be recolorable.

Edit:
Comparison vs. existing recoloring shaders.  PBR are on the outside, current shaders on the inside.

Overall I'm quite pleased with the quick conversions.  Some noticeable differences in the painted/foam textures that I was not expecting but still very usable (and easily fixed through a patch adjusting the colors).  Really want to find a way to expose the metallic value as a slider in the recoloring GUI... but that might go into the 'long term plans' as it would would be very difficult to adapt the current setup for it.

Edited November 5, 2017 by Shadowmage

[vossiewulf]

1 hour ago, Shadowmage said:

Also realized that there is a fairly easy way for me to convert the existing 'recolorable' textures to use the PBR setup by simply adding in some metallic maps (and/or metallic slider to the GUI).  The existing textures are already setup in a 'base color' + 'roughness' + 'occlusion' type setup; all it would take would be to add in the metallic channel to the specular maps (which are really roughness maps), and then all of the existing recoloring setups could be converted quite easily.

Metal tape is again in teh awesomes category, that really does look exceptionally cool. As in fact does the heatshield, very sweet capturing the metal mesh. I was just watching a couple shows on the Apollo CM, what I saw was a bit redder, a bit more saturated, and the finished product was maybe 35 on the roughness scale if 0 is perfect shiny. There was also visible roughness variation in circular patterns, looked like they did the final smoothing steps by turning the whole thing on a lathe and the result was visible circular stripes. I see that as being quite close, except the panel lines, Apollo had none, that looks more like Orion.

One thing I wonder about with that heat shield is the incredibly manual process of making them, where filling each hole took like 30 seconds of very careful dispensing and even then they had to go back and drill out and refill lots of holes. Seriously, they couldn't take an oversize/overthickness piece of the metal mesh and completely embed it in the resin with zero voids and then machine the whole thing to shape/size? Or use fiberglass layers between thick layers of resin stretched over a form, make it over-thick, bake it, then machine down the outside. The process they used looked like they sat down with the goal of hitting a man-hours home run.

[Jimbodiah]

If anyone wants a patch to convert the current RCS blocks (sstu and vanilla) and MUS into hypergolics:

http://jimbodiah.com/ksp/sstu/MP_Hypergolics.cfg

I can add it to the OptionalPatches folder if Mage likes, or otherwise to my own pack.

Edited November 5, 2017 by Jimbodiah

[Sudragon]

46 minutes ago, Jimbodiah said:

If anyone wants a patch to convert the current RCS blocks (sstu and vanilla) and MUS into hypergolics:

http://jimbodiah.com/ksp/sstu/MP_Hypergolics.cfg

I can add it to the OptionalPatches folder if Mage likes, or otherwise to my own pack.

Nifty.

Does it totally convert or allow switching?

 

[Jimbodiah]

Dude, I am happy I can make MM patches to replace stuff, let alone write plugins that actually do something    It's just an intermediate, replaces MP outright. Mage will make the real deal at some point.

Edited November 5, 2017 by Jimbodiah

[Shadowmage]

4 hours ago, vossiewulf said:

Metal tape is again in teh awesomes category, that really does look exceptionally cool. As in fact does the heatshield, very sweet capturing the metal mesh. I was just watching a couple shows on the Apollo CM, what I saw was a bit redder, a bit more saturated, and the finished product was maybe 35 on the roughness scale if 0 is perfect shiny. There was also visible roughness variation in circular patterns, looked like they did the final smoothing steps by turning the whole thing on a lathe and the result was visible circular stripes. I see that as being quite close, except the panel lines, Apollo had none, that looks more like Orion.

 

Revised the heat shield material a bit.  The paneling lines have a slider that controls their width, so simple enough to set that to 0 to turn them off.  Added some per-honeycomb color variation (that was fun to figure out), and increased the overall smoothness to give it a slight gloss effect.  Slight tweaks to colors, more red, more saturated, decreased brightness.  Have not yet worked on adding in any other noise/details, but its looking pretty good.  Its a bit lighter color than the image would make it seem.. as it is reflecting the dark wall behind it quite a bit, so might make it a bit darker still; I'll see what it looks like in space.  I've intentionally left the metal honeycomb as slightly raised and with a slightly higher smoothess value to add a bit of base detail to the texture.

Edit:
Think its a keeper:

Generated entirely by a bunch of code/mixing....

Edited November 5, 2017 by Shadowmage

[vossiewulf]

6 minutes ago, Shadowmage said:

Revised the heat shield material a bit.  The paneling lines have a slider that controls their width, so simple enough to set that to 0 to turn them off.  Added some per-honeycomb color variation (that was fun to figure out), and increased the overall smoothness to give it a slight gloss effect.  Slight tweaks to colors, more red, more saturated, decreased brightness.  Have not yet worked on adding in any other noise/details, but its looking pretty good.  Its a bit lighter color than the image would make it seem.. as it is reflecting the dark wall behind it quite a bit, so might make it a bit darker still; I'll see what it looks like in space.  I've intentionally left the metal honeycomb as slightly raised and with a slightly higher smoothess value to add a bit of base detail to the texture.

Fact is it's already the best Apollo heatshield ever modeled, so yeah you could stop here and walk away buffing the nails.

However, for the sake of obsessive perfection, not that either of us know anything about that, but it still needs to move red a bit, the one I saw on video was even redder than my sample above. If you just got a snap look at it and someone asked you what color it was, you'd have said red. In HSL, its hue was 8-12/255  and saturation... bah, describing colors is not a great way to get things done. Here done in five minutes from memory. Somewhere in this range.

And this looks much more like the one I saw than the honey-tan colors - 

 

The per-cell variability was a great idea, several notches realism up.

And although it looks cool, the mesh didn't protrude, it was a level surface. Correct is set accurate metal/roughness values for both and remove the height channel data, the hex cells won't be quite as visible but will be more accurate.

[T-10a]

2 hours ago, Jimbodiah said:

Dude, I am happy I can make MM patches to replace stuff, let alone write plugins that actually do something    It's just an intermediate, replaces MP outright. Mage will make the real deal at some point.

For the RCS blocks, I've got the fuel switching covered. This pretty much uses the current propellant switching & Modular RCS functions from the 8-way RCS block and adds it to the SSTU rcs. You could probably mess with it a bit and add it to ALL rcs blocks if you wanted to, but this is a proof of concept. In my current setup, I even added a custom HTP fueltype for my Hardmode Propellants setup externally (based on prior discussions on Oxidiser boiloff). That Hardmode propellant config may be seen later in either this topic or a new one.

DISCLAIMER: I hold no responsibility for any bugs here, as the config was ripped and modified from a WIP part.

https://pastebin.com/ppuVy25A

Edited November 5, 2017 by T-10a

[vossiewulf]

 

[Pappystein]

11 hours ago, vossiewulf said:

Metal tape is again in teh awesomes category, that really does look exceptionally cool. As in fact does the heatshield, very sweet capturing the metal mesh. I was just watching a couple shows on the Apollo CM, what I saw was a bit redder, a bit more saturated, and the finished product was maybe 35 on the roughness scale if 0 is perfect shiny. There was also visible roughness variation in circular patterns, looked like they did the final smoothing steps by turning the whole thing on a lathe and the result was visible circular stripes. I see that as being quite close, except the panel lines, Apollo had none, that looks more like Orion.

 

One thing you need to keep in mind.  The video you are watching is of VERY poor picture quality (I mean the guy is somewhere between green and orange with brick red shadows for skin color in the thumbnail scene!)   That is not a great environment to judge color... in fact it is a down right rotten one.  

 

While the above video is bit of a marketing educational video, it clearly explains in plain American English why I am making this point.  And other than the fact that I have used some of this companies software in the past I have no affiliation with them.   It was just the shortest most concise video I could find to explain this.  The above video does not even touch on the fact that the camera operator likely didn't adjust their camera to the environment it was working in (White balance, Luminosity tests at the lens and at the subject et al.)

 

 

 

[vossiewulf]

1 hour ago, Pappystein said:

One thing you need to keep in mind.  The video you are watching is of VERY poor picture quality (I mean the guy is somewhere between green and orange with brick red shadows for skin color in the thumbnail scene!)   That is not a great environment to judge color... in fact it is a down right rotten one.  

While the above video is bit of a marketing educational video, it clearly explains in plain American English why I am making this point.  And other than the fact that I have used some of this companies software in the past I have no affiliation with them.   It was just the shortest most concise video I could find to explain this.  The above video does not even touch on the fact that the camera operator likely didn't adjust their camera to the environment it was working in (White balance, Luminosity tests at the lens and at the subject et al.)

All good points. But I've been doing paying graphics work off and on since the early 90s so I've been calibrating for a while. The point wasn't that the color in the video is exactly right, but that the color was clearly not the honey-milk chocolate color he tried, which is much closer to Orion's. To me it looks like it started out as a red-orange and has faded over time in most of the samples I saw to a more yellow color except for the one I posted above.

And I've been involved in aviation history and military history in general forever (but for the life of me I can't figure out the purpose of the KSP weapons mods) and can't begin to count the pitched duels I've fought over colors of things over the years  In the end though I think it's irrelevant here and I've told him twice he's done already, but since he is going to extreme lengths - tape, metal mesh (you don't want to know how tricky that was), etc., it seems he's fairly serious about getting as close as he can with the showcase for his new spiffy PBR shader. So when he releases it, we'll feel a great disturbance in the Korce, as if millions of KSP players suddenly cried out and went "WHOA, DUDE!"

That being the case, trying to help him get there. I stick with my quick drawing above as my best guess as to the color, but not enough data so a guess. Mage will make up his own mind as to what he wants.

All that said, like I mentioned all your points are valid and should be considered by anyone who decides to get involved in any of the various Color Wars across the internet. 

[Jimbodiah]

This is not a realism mod, I don't think we should get so uptight as to have calibrated colors etc. Just thinkg recoloring tool for the heatshield

[Shadowmage]

On 11/4/2017 at 3:55 PM, vossiewulf said:

Quick bug (maybe) report, recoloring UI doesn't seem to work for the SSTU - SC-GEN - PDC - Custom Decoupler. Ok, it's just slightly possible this naming convention was created by an engineer, I especially like the dashes with or without spaces to indicate group or specific object variant. Anyway, at least I can't get recolor to change anything on that decoupler, ditto the probe core. And it seems that certain texture choices disable recoloring, like when I have the magic fuel tank set to have a gold round dome nose, I can no longer recolor that section. Not exactly a critical issue but if at some point you find yourself looking at it, a pass through all the cases looking for ones where either the recolor button shouldn't be available on the UI, or available but with some options grayed out, would probably be a useful UI consistency activity.

Hmm...  I'll have to take a look at the decoupler / probe cores.  Certainly remember being able to recolor them just fine.  Probably going to be getting all new textures here before too long (procedural substance).

As to the GUI -- would be very time consuming to setup.  Currently the GUI has no knowledge of what a texture set is, or what texture set is on a part, or if the texture set supports recoloring/# of channels.  Texture sets have no knowledge of what shader they use, and thus cannot be aware of what recolor channels they support (or if they even support recoloring).  It was about the only way to structure things to allow for the entire system to be used with arbitrary shaders.  If I start making the GUI's /etc shader-aware... then they will only ever work with the specific shaders that they are hard-coded to work with (or perhaps a config-defined list).  Would also require additions/changes to every texture-set definition in order to track if it supports recoloring, and what channels it supports.  Certainly could be done, but is many hours of code-side work, and even more on the config end of things. 

I suppose the (best/better) time to address all of this would be -before- I release it all as a stand alone mod.  A few other UI+shader level feature improvements that I'd like to make as well, such as including the MET channel as user-configurable.  My hesitance so far would be that it would (most likely) be be craft/vessel/save game breaking if I make the changes -- will require that additional data be stored for each recolorable segment.  Currently a single Vector4 / Color value is stored per-section; adding in the MET control will require that additional values be stored to represent that data.

I guess I'll start writing up the development docs on it and start figuring out how bad the breakage will be.

 

19 minutes ago, Jimbodiah said:

This is not a realism mod, I don't think we should get so uptight as to have calibrated colors etc. Just thinkg recoloring tool for the heatshield

Well, the heat-shields won't be supporting recoloring (don't currently, no plans to add that in).  The material I created supports easily changing of the color, so its really as simple as specifying a base color value.  But I'm also not that concerned with 100% color accuracy, and think that I like the current color scheme.  Might add in some higher-order particulate type noise to the fill, but I'm pretty happy with where it is at.

 

 

On 11/4/2017 at 1:32 AM, vossiewulf said:

By the way, you should experiment with real high poly/low poly + normal map  modeling flow, with correct environmental reflections I think the difference will be noticeable enough to do that moving forward. At the same time I doubt think the difference is a big enough improvement to consider redoing previous models.

[...snip...]

Yeah, my problem with the whole high-poly/low-poly modeling setup is.... time.  I really can't afford to increase my modeling time by 2-3x, unless it is going to save me that much time in other steps, and I can't see it doing that.  It might save a small bit of time by being able to bake out a base NRM map rather than hand-create one... but it really doesn't take me long to make the base NRM setups anymore.  I've also never found any automated setups that can convert between HP and LP -- they've all just made a mangled mess of the resultant LP mesh -- so I quit even trying to use HP, and model directly in LP.

[Jimbodiah]

NB: I have no problems recoloring the PC or PDC parts on the last release.

[Pappystein]

9 hours ago, vossiewulf said:

All good points. But I've been doing paying graphics work off and on since the early 90s so I've been calibrating for a while. The point wasn't that the color in the video is exactly right, but that the color was clearly not the honey-milk chocolate color he tried, which is much closer to Orion's. To me it looks like it started out as a red-orange and has faded over time in most of the samples I saw to a more yellow color except for the one I posted above.

And I've been involved in aviation history and military history in general forever (but for the life of me I can't figure out the purpose of the KSP weapons mods) and can't begin to count the pitched duels I've fought over colors of things over the years  In the end though I think it's irrelevant here and I've told him twice he's done already, but since he is going to extreme lengths - tape, metal mesh (you don't want to know how tricky that was), etc., it seems he's fairly serious about getting as close as he can with the showcase for his new spiffy PBR shader. So when he releases it, we'll feel a great disturbance in the Korce, as if millions of KSP players suddenly cried out and went "WHOA, DUDE!"

That being the case, trying to help him get there. I stick with my quick drawing above as my best guess as to the color, but not enough data so a guess. Mage will make up his own mind as to what he wants.

All that said, like I mentioned all your points are valid and should be considered by anyone who decides to get involved in any of the various Color Wars across the internet. 

Thanks for A) clarifying you understand about color calibration and B) for not leaving me alone in the world of Calibrated displays   Ok since I have calibrated close to 5000 displays I know I am not alone but it is a sharp minority!

I have a photo somewhere of an Apollo Capsule on a test stand with an un-used intact heat shield.  The lighting isn't great in it but as I remember (and yes I know visual memory is a whopping 7 seconds) I would say it was slightly yellow (as in the red color in it was ever so slightly closer to Yellow or Orange more appropriately on the CIE chart than what you are showcasing) than yours but not near the Honey tan color as you described Shadowmage's coloration.  Now if I could just find the photo again....   Ah never-mind Wikipedia to the rescue!

 

https://en.wikipedia.org/wiki/AVCOAT#/media/File:Avcoat.jpg

The right one is listed as 5026-39 which is the final formulation of AVCOAT used on Apollo.  The Left one was the earlier formulation used that was not used by NASA for manned capsules.   I am unsure about the name for the Formulation for Orion but the Formaldehyde needs to be removed so the modern AVCOAT might not be related to the previous versions except that they started there when developing the Orion's heat-shield.

Given NASA took these images for testing purposes I would be willing to bet that the cameras were properly white balanced and dialed in in for the most "life like" reproduction they could do with wet film.

 

 

 

[Shadowmage]

Random SS... unfinished textures and all... but the lighting... wow

 

And, uh... really not sure what is going on here.  Cool looking and all, but... what?   --
( I think that I'm actually rendering the atmosphere on top of the planet, and those colors are the atmosphere decay coloring that is normally obscured by planet geometry )

 

Did quite a bit of work today on adding in the metallic control to the recoloring GUI and all the systems that interface with it.  As a bonus, it will now only display section controls for currently enabled sections/sections with recolorable texture sets (pending adding some additional values to all of the config files). (note only body section is displayed in GUI; nose/mount sections will show up when they have eligible texture sets).

With the addition of the metallic slider to the recoloring system, the entirety of the PBR inputs are exposed for user control; base color, specular/gloss, and metal values can all be controlled on recolorable sections of models.  I think I managed to add in the new feature(s) without breaking existing craft files, which is excellent news as I was almost certain that it would break existing color values on fairings/decouplers/etc.

[MaeharaProjekt]

Pretty much picked my lower jaw and reattached it with space tape and thermometer hinges.

@Shadowmage, your work makes me giddy and maybe even a little breathless.

Wow. Just... yeah.

Wow.

Thank you!

[vossiewulf]

Another BTW mini-bug report - I'll have to try it again to be completely certain, but I think from two experiences that if you do a recolor, and then something else (place/offset/etc) and then undo that something else, the recolor gets undone and you can no longer get any right-click UI with those objects and have to exit and re-enter the VAB to get the SSTU part to reinitialize everything and get itself back into a correct state.
 

16 hours ago, Shadowmage said:

Yeah, my problem with the whole high-poly/low-poly modeling setup is.... time.  I really can't afford to increase my modeling time by 2-3x, unless it is going to save me that much time in other steps, and I can't see it doing that. 

I wouldn't do that either, good thing it doesn't take that long  Shouldn't take more than maybe 33% extra and that's on a complex model. Simple models it's even less. Go read about HP/LP modeling strategies, the important point is to minimize the cases where only way to make an LP part is to weld vertices. Doing it right also means make full use of a modeler's procedural features, MAX is very good at allowing you to walk back in the modifier stack and change primitive properties like # of cylinder sides, so LP objects can often be spit out at the end with a few clicks.

Also sometimes it makes sense to make the LP part and then add complexity to it for HP, sometimes the other way around.

Since you're using SP now you need to make full use of the hard surface stamps and alphas painting on the height channel to generate all your detail, this keeps the geometry simple and clean and that makes HP/LP easy. It's a slightly different way of modeling but I promise with a bit of practice it's not a hassle, the benefits are worth it.

Benefits:

• Better appearance, everything benefits from having a normal map baked from a HP that is higher poly than you use standard - e.g. 64 side cyliners.
• Renders faster - cake and eat it too, looks better but renders faster as the in-game rendered geometry should be lower-poly than your standard models.
• Creating detail with stamps in the height channel is 10,000 times faster than modeling, and moving as much of your detail as possible into the normal map makes the in-game models even lower poly and more efficient.
• Everyone uses it now, almost ubiquitous, and they wouldn't be if it took twice as long.
• Users will love it so much they will shower you with Rave Burger gift certificates.
• Yes we make Powerpoints at work every day.

Give it a spin on something medium, neither easy nor super complicated, with enough elements to make you think it through. That's the most important part, thinking it through first, if you do that it should be quite easy.

[Shadowmage]

10 hours ago, vossiewulf said:

Another BTW mini-bug report - I'll have to try it again to be completely certain, but I think from two experiences that if you do a recolor, and then something else (place/offset/etc) and then undo that something else, the recolor gets undone and you can no longer get any right-click UI with those objects and have to exit and re-enter the VAB to get the SSTU part to reinitialize everything and get itself back into a correct state.

Please file a github issue ticket on that, and include the KSP.log file.  Seems like something that needs to get fixed up, but I'll need the log to know where to start investigating.

 

10 hours ago, vossiewulf said:

I wouldn't do that either, good thing it doesn't take that long  Shouldn't take more than maybe 33% extra and that's on a complex model. Simple models it's even less. Go read about HP/LP modeling strategies, the important point is to minimize the cases where only way to make an LP part is to weld vertices. Doing it right also means make full use of a modeler's procedural features, MAX is very good at allowing you to walk back in the modifier stack and change primitive properties like # of cylinder sides, so LP objects can often be spit out at the end with a few clicks.

Also sometimes it makes sense to make the LP part and then add complexity to it for HP, sometimes the other way around.

Since you're using SP now you need to make full use of the hard surface stamps and alphas painting on the height channel to generate all your detail, this keeps the geometry simple and clean and that makes HP/LP easy. It's a slightly different way of modeling but I promise with a bit of practice it's not a hassle, the benefits are worth it.

Yeah, I think part of my problem may be that Blender doesn't appear to include any form of 'procedural modeling tools' (at least that I'm familiar with).  It does have a modifier-stack setup, but the modifiers are not anything that I would think useful for high-poly modeling.  The main two that I'm aware of are 'subsurface division' (adds tons of edge loops to meshes, adding smoothing to low-poly meshes), and 'simplify' (which takes a high poly mesh and just makes a terrible mess out of it).  There is certainly nothing that would let me adjust the # of sides on a cylinder or anything like that -- the geometry is whatever you specified when it was initially created.  It does have a few non-mesh based tools that are similar to what you describe (bezier-curve based geometries), but as soon as you convert them to a mesh (e.g. to unwrap, or join with existing mesh), it becomes 'static' and can no longer be adjusted procedurally.

Perhaps this is something that I'll investigate in the distant future, but I'm in no rush to do it now (unless someone has some accessible docs on how it is all supposed to work in Blender; and even then, it had better be dead simple to implement).

[atomontage]

Found an easy-to-fix bug. Well I think it is easy to fix.

Engines incorrectly calculate their thrust upon copying (if set to be with 2 or more chambers).

I've created a github issue as well.

Posting here so ppl will not have to worry if they encounter it.

(Tested on pure KSP 1.3.1. All info included in the issue.)

Thank you for this great mod! Love it.

I wish DangIt! properly recognized many SSTU parts, but its a known DangIt! issue I think to not recognize procedural stuff.

[Shadowmage]

15 hours ago, vossiewulf said:

Give it a spin on something medium, neither easy nor super complicated, with enough elements to make you think it through. That's the most important part, thinking it through first, if you do that it should be quite easy.

Doing some... quick experiments... on a fairly simple model that could benefit from some extra detail.  The places where the details are needed will normally not be visible, so seems very appropriate as a spot to experiment with baking in some details from a high(er)-poly mesh (back-side of a stand-alone heat-shield part).  If this works out at least I'll know the technical side of the Blender baking process, which has always been a nightmare in the past to figure out.  Will probably also give it a try directly in SP to see how that works, and how they compare.

Will still need to find some references on Blenders HP/LP setup/tools/workflow in the future for more complex models.  I'm fairly certain that Blender has to have some of the tools and features and I'm probably just not aware of them due to my low-poly/game-model focused learning/research.  Perhaps if I don't have to spend so much time manipulating verts in the models (to fix shading in the low-poly meshes) I might actually get an improvement to the overall model creation time.

 

4 hours ago, atomontage said:

Found an easy-to-fix bug. Well I think it is easy to fix.

Engines incorrectly calculate their thrust upon copying (if set to be with 2 or more chambers).

I've created a github issue as well.

Posting here so ppl will not have to worry if they encounter it.

(Tested on pure KSP 1.3.1. All info included in the issue.)

Thank you for this great mod! Love it.

I wish DangIt! properly recognized many SSTU parts, but its a known DangIt! issue I think to not recognize procedural stuff.

Thanks for the report, and for filing an issue ticket with all of the details

I have a possible solution in place already and will do some testing.  Thankfully (if it works) the solution to this particular problem was about as simple as it gets -- changing an internal field declaration from private to public so that it gets serialized when the part is cloned in the editor (hmm.. or maybe I can just mark it as [Serializable]...).  Some silly stuff has to be done sometimes to work around KSPs quirks.  Will update the issue ticket with more details.