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

[Shadowmage]

3 hours ago, JoseEduardo said:

quick question, to go along with the new Apollo CM, would it be possible to when you re-work the landers have an third model LEM-alike? you know, for 0.625m docking ports

Hmm... thats a toughie.  I have tried at least 4 times to model the LEM, and failed miserably every time.  Mostly due to lack of... proper engineering oriented schematics (i.e. milimeter precision measurements, with angles, curve parameters, etc).  Which I'm not likely going to find available for public access.  The shape of the thing is just so...ugh..not a real shape

However, I might consider either A: 'borrowing' the Nasa public-domain 3-d model (free to use, for any purpose!) and cleaning it up for game use, with custom textures, or B: Merely creating a smaller lander-can.  I kind of want to rework the landing pods a bit anyway for other unrelated reasons, so can probably work that in when I get to it.

Keep in mind though, reworking Lander-Core stuff is currently scheduled for 0.9.x; so... many months away.

 

2 hours ago, Jimbodiah said:

Nice white is fine, but I do love the FASA apollo CM/LEM though with the shiny texture and detailing. I just uninstalled them as I was getting tons of errors with that mod (15-20 lines per second). Too bad it's so buggy, I really loved a lot of his parts like the capsules and the launch clamps (hint, hint).

I -might- consider doing a silver/shiny texture given the new found ability to generate properly shaded meshes.  Can't stress how big of a deal this is to me... I've been trying for 6-months to find a way to fix normal shading;  just happens that it is a brand new feature in blender, and I just had to wait for them to make it usable. 

I'll at least mock up a couple of samples with silver/shiny texture and see how it looks.  No promises though, as I'm still not a huge fan of large patches of super-shiny without proper reflection support.

Launch clamps - not really planned, or of interest to me.  The stock ones work acceptably for my purposes.  Might consider it as a bonus feature after everything else is completed, but that will be a long ways out.

[Jimbodiah]

Cool!!!

[VenomousRequiem]

You know what, buddy? You said I'd hate it but a white Apollo sounds freakin' cool, so do that.

[Jimbodiah]

I say texture pack

[RedParadize]

I just noticed that RCS on the Upper stage don't seem to work. Can anyone confirm this? I a certain that I saw them working at some point, might be before pre5.

[Shadowmage]

White doesn't look too bad (very rough texture, nothing but flat color and some test hatch decals)

 

[frizzank]

Nice job on the engines, pipes are fun to model... Sometimes.

[VenomousRequiem]

45 minutes ago, RedParadize said:

I just noticed that RCS on the Upper stage don't seem to work. Can anyone confirm this? I a certain that I saw them working at some point, might be before pre5.

I think that I've had some trouble with this before, but I just... you know... pay so little attention to what I'm doing I think I just power through it.

[Shadowmage]

3 hours ago, RedParadize said:

I just noticed that RCS on the Upper stage don't seem to work. Can anyone confirm this? I a certain that I saw them working at some point, might be before pre5.

I can confirm that it didn't work in my quick test that I did an hour or so ago.  I likely broke the model/module somewhere again (its touchy interacting with stock modules).  Will investigate doing a patch for it tomorrow.

 

[RaendyLeBeau]

6 hours ago, Shadowmage said:

White doesn't look too bad (very rough texture, nothing but flat color and some test hatch decals)

 

looks really good! very good work. have again to follow a model more.

cheers !

[JoseEduardo]

I really like this white Apollo

[Shadowmage]

11 hours ago, frizzank said:

Nice job on the engines, pipes are fun to model... Sometimes.

Thanks, I learned a ton doing it.  More fun than the pipes was all the manifold joins I had to do for the turbos and stuff

 

1 hour ago, JoseEduardo said:

I really like this white Apollo

 

5 hours ago, RaendyLeBeau said:

looks really good! very good work. have again to follow a model more.

cheers !

 

Thanks guys, sounds like that will be what I'll go with for the time being.  Will revisit after 1.1 shader updates and see how the silver looks.

Here is the most recent progress shot of the CM texture -- added a few detail bits (mostly RCS), but it is still only like 1/2 done.

 

[curtquarquesso]

26 minutes ago, Shadowmage said:

Thanks guys, sounds like that will be what I'll go with for the time being.  Will revisit after 1.1 shader updates and see how the silver looks.

Here is the most recent progress shot of the CM texture -- added a few detail bits (mostly RCS), but it is still only like 1/2 done.

Wow. Very nice. 2.5m? Silver with the shaders that will be available in 1.1 would be awesome. I really can't wait.

One bit of critique. I think the forward facing windows could use a few more vertices. The side windows look fairly detailed, and the forward ones don't so much. 

Nice work.

[ComatoseJedi]

51 minutes ago, Shadowmage said:

Thanks, I learned a ton doing it.  More fun than the pipes was all the manifold joins I had to do for the turbos and stuff

 

 

 

Thanks guys, sounds like that will be what I'll go with for the time being.  Will revisit after 1.1 shader updates and see how the silver looks.

Here is the most recent progress shot of the CM texture -- added a few detail bits (mostly RCS), but it is still only like 1/2 done.

 

Works for me. You planning on a launch escape cover with an integrated srb like with the Orion pod too?

[JoseEduardo]

1 hour ago, Shadowmage said:

Thanks, I learned a ton doing it.  More fun than the pipes was all the manifold joins I had to do for the turbos and stuff

 

 

 

Thanks guys, sounds like that will be what I'll go with for the time being.  Will revisit after 1.1 shader updates and see how the silver looks.

Here is the most recent progress shot of the CM texture -- added a few detail bits (mostly RCS), but it is still only like 1/2 done.

 

I feel bad saying this with @frizzank a few posts above, but now FASA will be only for the clamps and Titan for me

looking forward for the final result in the Apollo pod and the later 1.1 shiny one

11 minutes ago, lynwoodm said:

Works for me. You planning on a launch escape cover with an integrated srb like with the Orion pod too?

it just occurred to me... what if we had a rescaled SM and Orion LAS? in addition to the Apollo SM and LAS of course...

in fact... mage, would it be possible to have the Apollo and Orion SM and LAS (although I can't see the Apollo one matching Orion) all size-tweakable but in a pre-set state? like, both SM and LAS could rescale to 3.75m and 2.5m (and later to 1.875m and even 1.25, config-based), but of course, their default size would be the intended one

[RedParadize]

26 minutes ago, JoseEduardo said:

in fact... mage, would it be possible to have the Apollo and Orion SM and LAS (although I can't see the Apollo one matching Orion) all size-tweakable but in a pre-set state? like, both SM and LAS could rescale to 3.75m and 2.5m (and later to 1.875m and even 1.25, config-based), but of course, their default size would be the intended one

That sounds like allot of IVA.

[FiiZzioN]

On 12/9/2015, 11:31:59, Shadowmage said:

And, on the related subject of re-entry / heating -- Working on laying out the groundwork for a custom ablator/heat-shield module to be used by the upcoming capsules.  As apparently the stock module has some issues with integrated parts, this will be a full-custom setup - and probably much more feature filled than the stock one.

Spoiler

Requirements:

• heatShieldVector - Heat-shield 'shielded' direction vector to determine if heatshield is facing the airstream and should ablate/protect.  The more it is facing the air-stream, the more effective it is.  (will have a slight 'grace' area where you can be slightly off-vector without too much bad effect).  This means the heat shield will only protect a part if oriented properly  -- no more heat shields losing their ablator during launch.
• minEffectiveDot - minimum dot product between wind and heat-shield direction where heat shield will still be effective (dot product is basically the angle between two vectors, expressed as a range of 1 to -1)
• maxEffectiveDot - the dot product at which the heat shield is most effective (at higher dot products than this, it will be 100% effective; it is this that provides some small off-perfect 'grace' area).
• ablationStartTemp - temperature at which ablation will start; below this temp and the heatshield is just dead weight
• ablationMaxTemp - temperature at which ablation peaks -- beyond this temperature effective ablation rate will peak at 100% of maximal.
• Node/occlusion checking - even if facing the airstream, if the specified attach node has a part attached the shield will be considered 'occluded' and not function.  Can be used to 'stack' heat-shields for sequential use.  Undecided if this will use drag-cube occlusion checks such as the stock heatshield, or if it will be purely node based.
• ablation heat reduction is based on the material used for ablation -- using specific heat capacity/density of the material.

Would-be-nice:

• Allow for other types of heat-shield -- passive thermal soak, ejectable, active thermal soak, others?
• Allow for variance in the ablator material? (e.g. in-editor switching)  More dense = higher start temp, but more effective (use for super-high-speed re-entries, such as direct-return-from other planets)
• For non-ablating types of heat-shield, allow variance in shield materials; higher density = more soak potential, ??

Any ideas/input on that list of requirements?  Will be needing to get this module finished up for the command pods as well; the stock heat-shield module just doesn't cut it for integrated parts (and the config values make zero sense / difficult to tweak properly).

Any ideas/input on that list of requirements?  Will be needing to get this module finished up for the command pods as well; the stock heat-shield module just doesn't cut it for integrated parts (and the config values make zero sense / difficult to tweak properly).

 

Would there be any way to make this somewhat compatible with DeadlyReentry, or will we still need to go down the same route of removing the module and replacing it with DeadlyReentry's module?

Edited December 10, 2015 by FiiZzioN

[JoseEduardo]

4 minutes ago, RedParadize said:

That sounds like allot of IVA.

IVA for service module and launch abort system?

[RaendyLeBeau]

hi Shadowmage,

really good job as I see. !!

I have the list of parts and looked through the photos to. The list is really extensive, how large the packet is in MB about when it is finished.

am already looking forward to the completion, 

cheers !

Edited December 10, 2015 by RaendyLeBeau

[RedParadize]

1 hour ago, JoseEduardo said:

IVA for service module and launch abort system?

Sorry I misunderstood what you said. I am bad@english

[Shadowmage]

3 hours ago, curtquarquesso said:

Wow. Very nice. 2.5m? Silver with the shaders that will be available in 1.1 would be awesome. I really can't wait.

One bit of critique. I think the forward facing windows could use a few more vertices. The side windows look fairly detailed, and the forward ones don't so much. 

Nice work.

Thanks   The more I read on the Unity 5 shader setup, the more excited I get about it.  Finally, proper texture workflow/re-use.  I just read about the ability to use 4 separate UV maps -per mesh-.  So, one for Diffuse/specular/etc (shared texture), one for AO bakes, one for detail texture (e.g. decals, hand-made normal maps, other detail stuff; not all faces might even need detail textures), and a fourth for ? (lightmap, second detail texture set?).  Really, this should cut down a lot of time out of my texturing, as I can re-use the base textures/materials (e.g. silver metal, orange foam, white paint) and only need to create the separate detail textures for each part, instead of remaking the full texture for every part.

Sadly, the geometry for the CM is finalized.  Even a tiny change in it will require redoing 8-12 hours worth of work (just redoing the AO bake is 2-3 hours of redoing the model into bakable form, and an hour or more of waiting for it to bake, not to mention the many hours worth of texturing I have already done that would be wasted because of a new uv layout).  Also, there is not really any room for additional polys in those windows without changing the # of sides on the base cone; and as I want to maintain compatibility with stock parts, I'm stuck at a 24-sided cone.  For future reference, the last stage at which I will make geometry changes (without -very- good cause) is the AO bake stage -- after AO has been done initially any kind of geometry change requires redoing far too much work.  So, in the future, speak up earlier and I will likely accommodate your request.

I'll revisit the geometry after the 1.1 update, as I'll need to completely redo all the textures for everything anyhow, will be close to no extra time lost for updating the geometry a bit.

 

3 hours ago, lynwoodm said:

Works for me. You planning on a launch escape cover with an integrated srb like with the Orion pod too?

Yes; will be a full-cover affair, with truss-based motor-tower.  Likely modeled very closely to the Apollo LES.

 

3 hours ago, JoseEduardo said:

I feel bad saying this with @frizzank a few posts above, but now FASA will be only for the clamps and Titan for me

looking forward for the final result in the Apollo pod and the later 1.1 shiny one

it just occurred to me... what if we had a rescaled SM and Orion LAS? in addition to the Apollo SM and LAS of course...

in fact... mage, would it be possible to have the Apollo and Orion SM and LAS (although I can't see the Apollo one matching Orion) all size-tweakable but in a pre-set state? like, both SM and LAS could rescale to 3.75m and 2.5m (and later to 1.875m and even 1.25, config-based), but of course, their default size would be the intended one

Rescaling pods = nope; I have no real interest in that, nor would it be easily doable.  Each rescale would require its own part config file, as the setup for stuff like parachutes/etc would be so vastly different (and I do not intend on adding dynamic rescaling to the parachute/etc modules).  Sounds like a ton of extra work for no real added utility.  And as others mentioned, it would require a custom IVA for every part-rescale, and you hopefully know by now how I feel about doing IVAs.

Nothing stopping you from doing it yourself though.  If you have any questions regarding the config values for my custom modules, you know how to reach me

 

2 hours ago, FiiZzioN said:

 

Would there be any way to make this somewhat compatible with DeadlyReentry, or will we still need to go down the same route of removing the module and replacing it with DeadlyReentry's module?

As I do not use DeadlyReentry, I will not be going out of my way to support it. Also, I was under the impression that it was no longer needed given the updated 1.+ stock aero and heating mechanics?  And last I looked at the DR code, they merely used a slightly modified stock heat-shield module (was some months back, just after 1.0 was released, so might have changed by now).  As the entire point of my heat-shield is to solve the problems the stock heat-shield has regarding integrated parts, it sounds to me like replacing the SSTUHeatShield module with the DR one would merely bring those problems back.

[FiiZzioN]

26 minutes ago, Shadowmage said:

As I do not use DeadlyReentry, I will not be going out of my way to support it. Also, I was under the impression that it was no longer needed given the updated 1.+ stock aero and heating mechanics?  And last I looked at the DR code, they merely used a slightly modified stock heat-shield module (was some months back, just after 1.0 was released, so might have changed by now).  As the entire point of my heat-shield is to solve the problems the stock heat-shield has regarding integrated parts, it sounds to me like replacing the SSTUHeatShield module with the DR one would merely bring those problems back.

Maybe this will give you an idea of what different type of things DeadlyReentry adds to the stock heating mechanics. Link here, Go to the "Changelog" section and expand it to see what it does now. Maybe it'll  give you some more ideas to what you're planning to do with your heatshields? 

What DR does compared to what it used to do is add on to the effects of the stock heating mechanics instead of having its own system like it used to. So, I guess you could say it just makes reentry a tad bit harder than stock. 

Hopefully that answers your question.

Edited December 10, 2015 by FiiZzioN

[Shadowmage]

As I stated, I do not use DR, nor will I be making any special accommodations for its support.  Its current/previous feature set really doesn't come into the decision at all.

I would love to use mods such as DR and FAR, sadly as long as they have general widespread compatibility issues (e.g. breaking other mods' parts... have read countless threads of problems caused by DR/heating... randomly exploding parts, in completely unrelated mods), they are off the table for my games.  And as long as I am not using them, I will not be offering support for them or going out of my way to make things compatible with them -- THEY need to ensure compatibility with anything usable in a stock-balanced game, not making every other mod go out of their way to support them.

If/when those mechanics get added into stock, at that point I will start supporting them.

[curtquarquesso]

1 hour ago, Shadowmage said:

Thanks   The more I read on the Unity 5 shader setup, the more excited I get about it.  Finally, proper texture workflow/re-use.  I just read about the ability to use 4 separate UV maps -per mesh-.  So, one for Diffuse/specular/etc (shared texture), one for AO bakes, one for detail texture (e.g. decals, hand-made normal maps, other detail stuff; not all faces might even need detail textures), and a fourth for ? (lightmap, second detail texture set?).  Really, this should cut down a lot of time out of my texturing, as I can re-use the base textures/materials (e.g. silver metal, orange foam, white paint) and only need to create the separate detail textures for each part, instead of remaking the full texture for every part.

Sadly, the geometry for the CM is finalized.  Even a tiny change in it will require redoing 8-12 hours worth of work (just redoing the AO bake is 2-3 hours of redoing the model into bakable form, and an hour or more of waiting for it to bake, not to mention the many hours worth of texturing I have already done that would be wasted because of a new uv layout).  Also, there is not really any room for additional polys in those windows without changing the # of sides on the base cone; and as I want to maintain compatibility with stock parts, I'm stuck at a 24-sided cone.  For future reference, the last stage at which I will make geometry changes (without -very- good cause) is the AO bake stage -- after AO has been done initially any kind of geometry change requires redoing far too much work.  So, in the future, speak up earlier and I will likely accommodate your request.

I'll revisit the geometry after the 1.1 update, as I'll need to completely redo all the textures for everything anyhow, will be close to no extra time lost for updating the geometry a bit.

Wow. Didn't know the process was so lengthy. Heh. For pre-1.1, it looks fantastic. Absolutely wait until 1.1 to make model tweaks. Have any resources on how to prepare for 1.1 textures?

[ComatoseJedi]

4 hours ago, JoseEduardo said:

it just occurred to me... what if we had a rescaled SM and Orion LAS? in addition to the Apollo SM and LAS of course...

in fact... mage, would it be possible to have the Apollo and Orion SM and LAS (although I can't see the Apollo one matching Orion) all size-tweakable but in a pre-set state? like, both SM and LAS could rescale to 3.75m and 2.5m (and later to 1.875m and even 1.25, config-based), but of course, their default size would be the intended one

MRS has one that really doesn't fit in anywhere, so I don't see why not making it rescaled. You'd have to fill in the notch for umbilical support, unless you still plan on implementing that.