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

[Shadowmage]

Just now, Jimbodiah said:

Gheghe, we only need two engines and one tank as well

No issue with just downward thrust on my end.

Well, if that one engine were modular and configurable, then yes (e.g. size, bell geometry, pumping type/efficiency, fuel type).  At least it would be enough for me; but I have always been a 'function before form' type person, and aesthetics are generally the last concern on my list (if a concern at all). 

Which is why it is so aggravating for people to request so many purely aesthetic models;  I already don't enjoy modeling (never have, never will), and having to sit down and do a set of parts that have zero functional difference.... makes my brain want to explode/melt.  It kills my motivation and willpower, and generally results in me wanting to do something else... -anything- else... like housework and other unpleasant tasks....as at least I get something useful out of that work.  The last thing you want is me having bitter feelings regarding doing modding work, as that is the single fastest way to make me quit.

So.. by all means, feel free to suggest stuff for models, but please keep the above in mind.  I'm making a huge compromise by even considering doing a few aesthetic variants for some of these parts; please don't abuse this by requesting absurd numbers of variants.  2-4 is about all that I have patience for for most parts.  Also... there is nothing stopping anyone else from doing these aesthetic-variants/models if they really want them; it doesn't require any special training (I don't have any for modeling/texturing), and I have intentionally designed my plugins so that they can use models from any source.

How about this -- I will add in the plugin-level support for angled and vacuum-variant nozzles, but I will not be modeling them for this initial set of parts (however, the ones I have modeled/am modeling will be angle-able in the VAB with the adjustment/slider).  I already have enough to model with all the SRB segments, nosecones, and the already planned/started nozzle geometries (looking at something like ~55 or so new .mu models for this set of parts; though will likely come down to only about ~20 distinct meshes spread across 3 textures in Blender.... which is still a bit of stuff to manage).

[Shadowmage]

49 minutes ago, JoseEduardo said:

about angled SRBs, I'm not 100% sure of that, but I remember reading that the Saturn MLV concepts, and other post-Apollo designs were going to use unchanged versions of the UA 1205 and 1207, so I don't think they were adjustables

I might be wrong though....

You are likely correct regarding their intended use/re-use; my statements were based purely on logical inference for the reasoning behind the angled nozzles. 

I could only think of two reasons -- ensuring exhaust is sufficiently clear from the center stack to prevent damage, and corrections for thrust differentials. 
The first should only be of concern for rockets where the nozzles of the solids are mounted above the bottom-plane of the core stage, or where the engine bells from the core stage might protrude into the exhaust stream a bit. 
The second would mostly be of concern where either the payload or SRBs were not setup symmetrically.  Fairly certain I've seen some pics of Atlas / Delta type rockets with odd/offset booster arrangements (e.g. I think I ran across one yesterday which only had a single SRB mounted on the core stage), where the vectored thrust should run through the COM to minimize torque.  I could be completely off on this though... I'm not really a rocket scientist/engineer... I just play one on the internet once in awhile.

Anyhow... I'm working on getting the plugin-side support for all this finished up today (as apparently I need a break from modeling).  This will include support for both vacuum and angled nozzle variants, and any combination of the two.  Will also include support for manually angling the gimbal while in the editor for any of the included nozzles, though their default orientation will be straight downwards (the angled ones will by default be angled).

As with the fuel tank/engine mounts, the rest of the nozzle designs and variants can be added over time/in the future as I have the time and patience to get them done.  There should be nothing preventing them from being done in the future, and it is only time/patience that is preventing me from doing them for the initial offerings.

 

Looking like I probably won't have a mid-week update this week, and the initial prototype of the MSRB part(s) will have to wait for the weekends' release.  I have not made sufficient progress at this point to warrant an updated testing release, and there would be nothing new to test.  However I should be able to have the prototype (untextured) model geometry done for this weekends' release, for at least a couple of variants -- should give sufficient usability to the MSRB parts that they could be tested for functionality.

[Jimbodiah]

Mage, don't go all out to the point of raging. Just make what you were planning and leave variants for possible future updates if you feel like it. We're (I'm) just excited and calling out ideas, we're not expecting them all to be implemented, let alone on initial release.

The angling is nice eye candy, but I dont see the need to make it adjustable (nozzle A is angles, B and C are not, no in betweens). If it's a hassle and you don't have the patience, just say no.

I wish I knew how to model so I could help out, but have zero experience with graphics with exception to photoshop work.

If you tell me what programs I need (Blender and...), I could give it a look over. Might combine it with gimp for the textures that you sent me a while back.

Edited February 3, 2016 by Jimbodiah
Zpelink

[Shadowmage]

31 minutes ago, Jimbodiah said:

Mage, don't go all out to the point of raging. Just make what you were planning and leave variants for possible future updates if you feel like it. We're (I'm) just excited and calling out ideas, we're not expecting them all to be implemented, let alone on initial release.

The angling is nice eye candy, but I dont see the need to make it adjustable (nozzle A is angles, B and C are not, no in betweens). If it's a hassle and you don't have the patience, just say no.

I wish I knew how to model so I could help out, but have zero experience with graphics with exception to photoshop work.

If you tell me what programs I need (Blender and...), I could give it a look over. Might combine it with gimp for the textures that you sent me a while back.

Don't worry, I'm a long ways off from doing any kind of raging.  Perhaps a bit frustrated at some times, but that is a why I make those posts -- to at least express a bit of that frustration before it becomes too much of a problem.  And yes, a good portion of it is probably due to me seeing suggestions as... something a bit more obligatory than they are intended to be.  That is a personal failing of mine that I have struggled with for... ever... but have only had limited success in suppressing and minimizing.  Once in awhile it gets the best of me, and you might see frustrated posts such as those.

So... thank you for your suggestions -- they are appreciated at the end of the day, even if they might frustrate me in the morning, and I'm sorry if I seemed a bit... aggressive regarding them; it was not intentional nor directed at any particular person.
 

In-Editor Nozzle Angling --  won't be / isn't / wasn't too hard.  I believe I already have it mostly implemented, but will need to do a bit of testing on it once I'm home from work.  It -should- allow the gimbal to be pre-angled between a range of angles set in the config for the nozzle.

On that note -- I have realized that an in-flight gimbal trim adjuster might be useful for other engines in general (okay, so, specifically for shuttles so that the default trim for just the main engine can be adjusted while in-flight).  Will give this a bit more thought over the next couple of weeks to see if it is truly needed/useful.

I'm still debating over the vacuum/atmo nozzle differentiation stuff -- it is certainly doable, but I might need to talk with Stratochief and/or NathanKell regarding the implications for RO patching and setup.  Would like to keep things compatible if at all possible.

 

Don't worry about the modeling stuff too much, unless you are seriously interested.  I would only recommend looking into learning modeling if it is something you think you would enjoy, and are prepared for some pretty steep learning curves.  However, if you are truly interested, feel free to contact me through PM and I'm more than willing to offer some pointers and help you get started (and can even offer .blend / model files if you needed reference material).

Note that I'm also not looking for or asking for people to contribute models or time to SSTU -- I'm mostly iterating that the plugin itself can handle whatever (properly built) models that are thrown at it if someone wanted to use them in their own personal games (or even released as a third-party add-on-parts pack for SSTU).

 

Anyhow... back to coding work for me for a few more hours.

[Jimbodiah]

22 minutes ago, Shadowmage said:

So... thank you for your suggestions -- they are appreciated at the end of the day, even if they might frustrate me in the morning, and I'm sorry if I seemed a bit... aggressive regarding them; it was not intentional nor directed at any particular person.

It's good that you do, as it means it's eating at you and will only pile up if we (the horde) are not stopped. I can get overly excited and eager to help, but it is only to help, not force you to do something you don't want to. It's hard to find a balance between energies, as we have different ways of looking at things and no idea when something is hard or easy. I wrote software for packaging machines for years (10+ synchronous axis servo controlled with scada etc etc), and often the "simple ideas" my boss came up with were the hardest to implement, and things he thought were hard would be rather easy a lot of times. He was not hindered by any knowledge, as I guess we are him in this situation. This lack of insight on our part can also contribute to frustration on your end... We don't need/deserve elaborate answers which only eat up more of your energy. Just say "yes, possible, maaaaybe in future update" or "no, too hard, won't be doing it".

A large issue is always that everything is just text in these messages; you can't get a real context of how people are trying to say something. Saying something trivial might come across as the last drop to set you off. Just yell "time-out" so we know when enough is enough    I am sure everyone only has the best of intentions, coming with suggestions and reports, but never look upon them as being demands. I kept nagging you about the nose cones, so guilty as charged. I'd love to see that stuff be implemented, but I am launching rockets without them as well.

"The road to hell is paved with good intentions".  

 

Edited February 3, 2016 by Jimbodiah

[blowfish]

1 hour ago, Shadowmage said:

On that note -- I have realized that an in-flight gimbal trim adjuster might be useful for other engines in general (okay, so, specifically for shuttles so that the default trim for just the main engine can be adjusted while in-flight).  Will give this a bit more thought over the next couple of weeks to see if it is truly needed/useful.

Might want to check out this mod which uses this plugin before you duplicate any work .

[Shadowmage]

Well, in-editor nozzle-angle adjustment works.

 

Has a conflict with RCSBuildAid that I'll need to sort out, but otherwise appears that it will work fairly well.

 

Edit:

And an updated nosecones/nozzles render with the addition of a 4th delta-styled nozzle;  this will be the initial selection of nosecones and nozzles available for the MSRBs.  Geometry for both is still a bit WIP, though they are pretty close to finished.  Mostly it will be the segments/skirts/etc that will have the majority of the detail for the model.

One thing that I'm considering is including the proper separation hardware in the models, that way -if- I do include the auto-jettison feature in the future the models are already prepared for it.  It would mostly mean that the nosecones and nozzles would have some slight geometry changes, though I think most of it would be done in the normal-map (and could be changed/added/removed through texture-swapping).

 

Edited February 4, 2016 by Shadowmage

[Jimbodiah]

Awesome!!!!!

[Shadowmage]

Before I get too far to alter it --  what are the feelings regarding the text on the sides of the SRB's?  (The 'CAUTION - Loaded Explosives' / etc text)

Currently I've unwrapped the segments to use mirroring, to cut the texture size/use roughly in half.  However, this prevents the use of -any- text (as it would be mirrored/reversed on half of the texture).

Do you guys want text on the sides of the SRB?  I feel it adds a bit more authenticity to them, but is certainly an 'optional' detail bit.

Should I re-unwrap the segments without mirroring, using roughly twice the texture area, so that I can add the text on the sides?

Edit:  This would take the texture from 2048x1024 to 2048x2048

Edited February 4, 2016 by Shadowmage

[blowfish]

47 minutes ago, Shadowmage said:

Before I get too far to alter it --  what are the feelings regarding the text on the sides of the SRB's?  (The 'CAUTION - Loaded Explosives' / etc text)

Currently I've unwrapped the segments to use mirroring, to cut the texture size/use roughly in half.  However, this prevents the use of -any- text (as it would be mirrored/reversed on half of the texture).

Do you guys want text on the sides of the SRB?  I feel it adds a bit more authenticity to them, but is certainly an 'optional' detail bit.

Should I re-unwrap the segments without mirroring, using roughly twice the texture area, so that I can add the text on the sides?

Edit:  This would take the texture from 2048x1024 to 2048x2048

I'd say see what you can do without doubling the texture area.  There are a few possible options which might work depending on the existing setup:

1. Only duplicate the texture on a few faces where the text is.  My experience is that there's usually enough empty UV space for this, but I haven't seen your UV maps so I don't know for sure.
2. Put the text on a transparent overlay.  KSP textures usually have alpha channels anyway (which control specularity), it just means that the text has to be on its own object with the shader set to transparent rather than specular (and of course that means that you don't get as much specularity control on the text but that's probably fine anyway - is anyone really going to notice?).

If it's not possible to add text without doubling the texture size then I'd say don't do it.  And I don't know how you feel about unwrapping but if it were me I'd try to avoid redoing it just about any way possible 

Edited February 4, 2016 by blowfish

[Shadowmage]

5 minutes ago, blowfish said:

I'd say see what you can do without doubling the texture area.  There are a few possible options which might work depending on the existing setup:

1. Only duplicate the texture on a few faces where the text is.  My experience is that there's usually enough empty UV space for this, but I haven't seen your UV maps so I don't know for sure.
2. Put the text on a transparent overlay.  KSP textures usually have alpha channels anyway (which control specularity), it just means that the text has to be on its own object with the shader set to transparent rather than specular (and of course that means that you don't get as much specularity control on the text but that's probably fine anyway - is anyone really going to notice?).

If it's not possible to add text without doubling the texture size then I'd say don't do it.  And I don't know how you feel about unwrapping but if it were me I'd try to avoid redoing it just about any way possible 

1.)  Good point / method.  Will see what I can do about implementing this.  Would still require fully re-unwrapping and laying things out.  Might be more work than just un-mirroring things; this way I need to manage both mirrored and non-mirrored portions, and somehow deal with the seam on one of the edges (or both edges....).  Hmm.... perhaps not the best choice then (I cannot stand visible seams, and doing it this way would mean I could not use any noise-textures, or else the seams would become readily apparent).

2.)  I had used this method in the past (on the old Series-A/B/C stuff).  Generally I found it not worth the hassle (and draw-calls); managing multiple meshes and materials just for some text.  Creates far too much work in the end.  It -does- work, and could be a potential solution, but not one that I want to get back into.

The other potential option would be to duplicate the avionics tunnel onto the other side of the segments (so it has a tunnel on both sides of the SRB), and use rotation-based-mirroring for the main segment sides.  However, this would result in text being visible on both the front and back of the SRB rather than just the back.  This would allow for using the existing UV layout, and would not require re-unwrapping much/at all, but I'm not sure that I want tunnels and text on both sides (would prefer the text is opposite the tunnel so that it gets hidden when the SRB is surface attached).

 

[MrMeeb]

Liking the look of the SRBs, especially as they're customisable length...like procedural srbs but prettier!  

Keep up the good work!

Any news on the shuttle? :3 

Edited February 4, 2016 by MrMeeb

[Shadowmage]

1 hour ago, blowfish said:

I'd say see what you can do without doubling the texture area.  There are a few possible options which might work depending on the existing setup:

[...]

So, after looking at things again regarding using UV space -- fully unwrapping with no mirroring on a 2048x2048 texture actually results in a much worse UV space;  have nearly a full 1024x area of unused texture, which is far too much to be acceptable.

That leaves me really with only #2 as an option even if I do dislike the workflow problems it creates.  Will give it a bit more thought.  Likely though will just not have text on them.

[Jimbodiah]

With/without is both fine by me.

[Shadowmage]

1 hour ago, MrMeeb said:

Liking the look of the SRBs, especially as they're customisable length...like procedural srbs but prettier!  

Keep up the good work!

Any news on the shuttle? :3 

Aye, should be a bit prettier than P-SRB's, though perhaps slightly less configurable (uses pre-set length increments rather than directly user-set); though there should be enough variants to allow enough variety in performance statistics and uses.

 

On Wednesday, February 03, 2016 at 2:17 PM, blowfish said:

Might want to check out this mod which uses this plugin before you duplicate any work .

Thanks, will look into that before I commit to any purely engine-related gimbal stuff.  Not sure how much I'll get out of it though, as it appears to be licensed under a no-derivatives license, which severely limits my potential uses for it.

 

49 minutes ago, Jimbodiah said:

With/without is both fine by me.

I'm -thinking- I'll be going the decals route (#2 from above).  I'm really not fond of the workflow, but I cannot see any other way to reasonably pull it off.  And it would allow for the decals to potentially be disabled or replaced though plugin and/or texture alteration.  It also saved me from having to re-unwrap/layout the UVs... so at least that's something...

Will -hopefully- have some initial test parts put together tonight to see how it all looks in game.

[Kerbal01]

What is SatelliteCore? Hinted on your github wiki page.

[01010101lzy]

The SRBs look awesome! Can't wait to try them out!

(But seriously, I have homework to do now)

[Shadowmage]

14 hours ago, DarthVader said:

What is SatelliteCore? Hinted on your github wiki page.

A planned set of parts to enable low-part-count satellites/probes.  I've updated the wiki page with a bit more info; the whole thing is months out at the earliest though.

 

And....

First preview of the actual SRB body geometry:

This is the 'smooth' / unsegmented SRB.  Yes, it still has two rings on it, for the upper and lower skirts; so it might not exactly mimic real-life geometry, but I needed a consistent mating mechanism to ensure that all the various bits had their AO line up properly... so everything has at least those two rings. 

Got this set of models exported and setup in-game last night.  Still need to do a lot of the config balancing for it, and export/setup the other three sets of SRB models, all the nosecones, and all of the nozzles.  Hoping to have these all available in-game for tomorrows' release, though the nosecones and nozzles will be untextured/white for this release as there is no way I'm going to have time to unwrap/texture them all.  The SRB segments will have basic first-pass texturing only, but all should have at least some texture on them.

 

 

Edited February 5, 2016 by Shadowmage

[Shadowmage]

5m segment x 4 segment, testing basic textures...

(there are also 3.2m and 2.5m long segment - segmented SRBs, for a bit of variety; you'll see those with tomorrows release)

 

 

[Jimbodiah]

Shut up and take my money! 

[blowfish]

13 minutes ago, Jimbodiah said:

Shut up and take my money! 

No that's wrong

[Jimbodiah]

Whahahah!!!

[V8jester]

Dude that was so funny!!!

[blowfish]

No idea who posted that image first, actually.  I've seen it floating around in a few threads.

[Sudragon]

5 hours ago, Shadowmage said:

A planned set of parts to enable low-part-count satellites/probes.  I've updated the wiki page with a bit more info; the whole thing is months out at the earliest though.

 

And....

First preview of the actual SRB body geometry:

This is the 'smooth' / unsegmented SRB.  Yes, it still has two rings on it, for the upper and lower skirts; so it might not exactly mimic real-life geometry, but I needed a consistent mating mechanism to ensure that all the various bits had their AO line up properly... so everything has at least those two rings. 

 

 

Dont worry about the rings.

Tolkien included rings and look how that worked for him.