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

[Shadowmage]

2 hours ago, Mike` said:

If you don't require the sizes to match real life, you could leave those alone and only adjust the engine and tank weights to get real TWR and tank dry mass values. That could then be played in 1x or 0.64x scale system?

Not sure if it's worth it though, i have yet to try a  larger scale system, will probably do so some time using RSS.

 

Should i submit an issue for this?

Yes please.  The transform looked okay in blender, so will require more investigation.

1 hour ago, tater said:

PBR doesn't blow up on my Mac.

The test tank says "Silver Metallic," but it's the dark, gunmetal color, so the lights in the VAB, and the sun in orbit are the only reflections I see.

Also, in the VAB, if the any part is attached to the test tank, and you change the test part texture, the attached parts change texture as well to match (all parts, even stock).

 

Yeah, apparently I had a typo in one of the configs, checking now and will upload a new PBR test folder (with J2 engine textures/configs).  Please try the new link: https://github.com/shadowmage45/SSTULabs/releases/tag/PBR-0.1.0.2

Even then the in-editor reflections will not work until you open the reflection-debug menu (truck looking icon), and hit the 'force refl update' button.  Should be fine if you launch to flight scene though.

 

Getting closer...

[vossiewulf]

10 minutes ago, Shadowmage said:

Schwing!

Edited October 22, 2017 by vossiewulf

[StickyScissors]

If these new reflections (and, be extension, color changing menu options?) work out, i might be able to get the shiny merlins after all.

-

and maybe even the rare matte black merlin

 

[JoseEduardo]

holy sh.....uttle... let's go with shuttle.... I leave for a (long) while and return to find in-game editor recoloring

kinda made my textures useless (not complaining), but awesome, now I can make a golden rocket worthy of a sheik

still didn't try that PBR shading though, just saw the link lol

[tater]

Truck looking icon?

[tater]

OK, in the new link I get the truck icon.

And WOW.

Just wow.

 

[Temeter]

Yeah, looks pretty damn neat!

Performance-wise it also runs really well. Had a 90 tank craft running perfectly fine (could hear my GPU fans for once in KSP). DX11 can cause some performance issues for me, but even then, the craft didn't cause any additional detoriation either. GPU load seemed pretty instable, jumping between 20 and 100%, which probably is a KSP thing either way.

Felt like the F-1 sometimes caused a slight bit of lag when updating reflection, but the FPS was relatively stable as well, even with larger numbers.

I couldn't find any option to activate the reflections on the CM and SM, though? Am I missing something?

Edited October 23, 2017 by Temeter

[Shadowmage]

10 hours ago, JoseEduardo said:

holy sh.....uttle... let's go with shuttle.... I leave for a (long) while and return to find in-game editor recoloring

kinda made my textures useless (not complaining), but awesome, now I can make a golden rocket worthy of a sheik

still didn't try that PBR shading though, just saw the link lol

Yeah, there have been quite a few changes while you've been on vacation

Let me know if you need a hand getting anything sorted out for your expansion pack configs/patches.

 

1 hour ago, Temeter said:

Yeah, looks pretty damn neat!

Performance-wise it also runs really well. Had a 90 tank craft running perfectly fine (could hear my GPU fans for once in KSP). DX11 can cause some performance issues for me, but even then, the craft didn't cause any additional detoriation either. GPU load seemed pretty instable, jumping between 20 and 100%, which probably is a KSP thing either way.

Felt like the F-1 sometimes caused a slight bit of lag when updating reflection, but the FPS was relatively stable as well, even with larger numbers.

I couldn't find any option to activate the reflections on the CM and SM, though? Am I missing something?

Hmm.. I'll have to check the CM/SM patches -- it should be an extra texture-set option in the editor (just click the texture set >> button a few times).

GPU load -- not surprising it is a bit spikey; once per second, I render one cube-map face per frame, and feed that to the reflection probe, who then spends another ~14 frames updating its internal data and doing the blur.  On the frames where none of that is happening (40 out of 60), the load should be much lower.

 

9 hours ago, tater said:

OK, in the new link I get the truck icon.

And WOW.

Just wow.

 

 

11 hours ago, StickyScissors said:

If these new reflections (and, be extension, color changing menu options?) work out, i might be able to get the shiny merlins after all.

and maybe even the rare matte black merlin

Silver - definitely.  Matte-black - certainly doable (and already was), but not sure if I'll be making that texture myself.

Edit:  Recoloring support not yet.  Possibly not at all -- I need to figure out the proper way to recolor the Standard shader, while still allowing me to make the textures with SP.  Currently I plan on getting recoloring working, but am not going to make any promises.

Edited October 23, 2017 by Shadowmage

[tater]

 

[Temeter]

2 hours ago, Shadowmage said:

Hmm.. I'll have to check the CM/SM patches -- it should be an extra texture-set option in the editor (just click the texture set >> button a few times).

GPU load -- not surprising it is a bit spikey; once per second, I render one cube-map face per frame, and feed that to the reflection probe, who then spends another ~14 frames updating its internal data and doing the blur.  On the frames where none of that is happening (40 out of 60), the load should be much lower.

I tried that, but couldn't switch to another texture for the SM (as if there is only one option), and only to normal and metallic for CM. No PBR surfaces.

Spikey load didn't make an issue for 90 tanks, and very little for F-1. Seems just fine, all in all.

Quote

Edit:  Recoloring support not yet.  Possibly not at all -- I need to figure out the proper way to recolor the Standard shader, while still allowing me to make the textures with SP.  Currently I plan on getting recoloring working, but am not going to make any promises.

One thing after another, I'd say. First the knife, then the bread.

2 hours ago, tater said:

 

Spoiler

 

 

 

 

 

Mine is bigger

Imagine building a metallic surface'd space station!

Or just giant, shiny space Transports!

Edited October 23, 2017 by Temeter

[Shadowmage]

16 hours ago, vossiewulf said:

That's pretty much what I meant. The poor support for animations is perplexing, but yes I'm sure you're right that that would be a pain. Is there any reasonably easy mechanism where we could have an attachment node at the end for the probes/satellites that could extend out of the bay?

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...

 

[Jimbodiah]

@Mike @T-10a  Adjusting the thrusts is no problem, that is a one line thing for every part with the EngineFX module. Adjusting the weights will have to be done for every individual part and it is not just the mass field as you would have to redefine more than just that, which is what RO does for SSTU parts. Hence just altering the ISP value acomplishes the same thing but in a single command for every part.

There is no way to do this other than go RO (maybe not real-fuels and the whoel overhaul), SMURFF or to use a gimmick patch like mine. You can spend all the effort of making an RO patch which will be outdated with every change to SSTU (changes, new parts) or just play the game with a compromise that works across all mods (not just sstu). I don't see this need to have all the numbers align with real world figures and act like ISP is a holy number that must not be touched: When you use a 3.2x scale system you are doing the exact same thing, just using stock parts and changing the planet size multipliers to get real-world behavior for their ISP. What's the difference between chosing RSS and adjusting the parameters of engines to match real world behavior? It's the same thing, but you are still not experiencing the real scale of RSS  This is why I also play SSRSS sometimes (none of those god-awful long wait times to get a transfer window), which is a stock scaled RSS with another patch to bring engine performance back to real life behavior (the opposite of my rss patch). In the end it's all the same thing, so why fuss over the ISP value?

[Shadowmage]

Hmm.. playing around with the LC fuel tank geometry a bit more -- trying out a slightly different bracing/frame arrangement (based on one of @tater's posted pics):

I think I like the bracing arrangement better than my previous layout.  Will require a few other minor adjustments to the existing geometry, but I think it will work out quite well.  Allows for easy setup for the segmenting of the middle sections of the tanks by repeating/stacking the central bracing.  Has a better bracing layout with the 'round' adapter in place.  Doing some testing to see how the other adapters/end-cap selections look...

Edit:

Looks like it will make nice probe-parts too; or small upper-stages...

Hoping to put the finishing touches on the reworked LC fuel tank geometry sometime this week.

Have narrowed down the list of available variants / simplified the variant geometry a bit.  Also adding in an 'inset' variant that has one or both ends with the center tank inset slightly, to allow for clearance from an upper-stage's engine, or allow for the lower-engine to be inset slightly into the bottom of the fuel tank without clipping.  Will come up with some renders of those after I finalize the geometry setup.

Edited October 23, 2017 by Shadowmage

[Temeter]

@Shadowmage I found the problem! The "TextureSets-SC-B - Apollo - PBR.txt" needs to be a cfg!

Much better:

Somehow it breaks the SM and throws nullrefs. Might be missing some dependencies *scratches head* ^{(edit, i mean really, who needs custom ressources :^)}

Considering the real moon picture (https://i.imgur.com/c4j4fBI.jpg), IMO the CM reflection could be a slight bit more clear (less blury), while the SM might have a more metallic and less plastic reflection (the clear difference between bare metal and grey painted parts is already pretty good tho!).

In any way, it looks really great!

Also, those shiny engine are <3

Edited October 23, 2017 by Temeter

[Shadowmage]

1 hour ago, Temeter said:

@Shadowmage I found the problem! The "TextureSets-SC-B - Apollo - PBR.txt" needs to be a cfg!

Much better:

 

Somehow it breaks the SM and throws nullrefs. Might be missing some dependencies *scratches head* ^{(edit, i mean really, who needs custom ressources :^)}

 

Considering the real moon picture (https://i.imgur.com/c4j4fBI.jpg), IMO the CM reflection could be a slight bit more clear (less blury), while the SM might have a more metallic and less plastic reflection (the clear difference between bare metal and grey painted parts is already pretty good tho!).

In any way, it looks really great!

Also, those shiny engine are <3

Good find on the config extension mismatch.  I was hastily trying to pack all of that stuff up yesterday and apparently goofed up more than one part of it (lots of typos...).

Will do some testing today to see if I can track down why the SM is spamming null-refs; probably more errors in the configs

Yeah, both the CM and SM could use being slightly more reflective.  I was trying to track down some apparent 'super-glossy' problems when I was working on their textures which is why they ended up as rough as they currently are (turns out the problem I was seeing was just DX9 not blurring the mip-maps properly).

So far all of the PBR textures in the testing pack are very much WIP.  I'll probably completely redo most them after I learn a bit more about SP and finalize my decision on if I'm actually going to use the PBR shaders (fairly certain I am, but still some testing needed).  The enhanced lighting, even on simple models (e.g. the SM in your linked image), is just too good to miss out on.

Still a lot I need to learn about using SP.  Seems like it will be an excellent tool for doing these PBR textures, but as with any good tool, you need to learn how to make the best use of it and use it efficiently.  As @vossiewulf points out, I'm going to need to find (or create) a lot more effect generators.  The ones included in SP by default are certainly usable, but limit what can easily be accomplished.

This week will probably see more development work on the F1 and J-2 engine textures, as well as another pass over the CM/SM, and finally, I'm going to try to get some of the tank and mount/adapter textures reworked as well.  Still trying to get the a Saturn-V stack setup using the PBR textures for a good example/visual testing pack (hopefully for a release this weekend).  Might even take a quick stab at converting the NASA-LEM model and getting it in-game (just for testing purposes/screenshots/giggles... it won't be sticking around).

[Temeter]

7 minutes ago, Shadowmage said:

Will do some testing today to see if I can track down why the SM is spamming null-refs; probably more errors in the configs

Sorry for the misunderstanding, I just left it standing as a joke. The edit is supposed to mean silly me forgot to copy over the CommunityResourcePack to gamedata, which broke the SM in quite curious ways (at some point it literally vanished from the part list).^^

Didn't really spot any issue with the parts, other than the known issue of editor reflections needing to be forced.

Quote

So far all of the PBR textures in the testing pack are very much WIP.  I'll probably completely redo most them after I learn a bit more about SP and finalize my decision on if I'm actually going to use the PBR shaders (fairly certain I am, but still some testing needed).  The enhanced lighting, even on simple models (e.g. the SM in your linked image), is just too good to miss out on.

Good luck! Some of the results are aleady spectacular.

[T-10a]

2 hours ago, Jimbodiah said:

@Mike @T-10a  Adjusting the thrusts is no problem, that is a one line thing for every part with the EngineFX module. Adjusting the weights will have to be done for every individual part and it is not just the mass field as you would have to redefine more than just that, which is what RO does for SSTU parts. Hence just altering the ISP value acomplishes the same thing but in a single command for every part.

There is no way to do this other than go RO (maybe not real-fuels and the whoel overhaul), SMURFF or to use a gimmick patch like mine. You can spend all the effort of making an RO patch which will be outdated with every change to SSTU (changes, new parts) or just play the game with a compromise that works across all mods (not just sstu). I don't see this need to have all the numbers align with real world figures and act like ISP is a holy number that must not be touched: When you use a 3.2x scale system you are doing the exact same thing, just using stock parts and changing the planet size multipliers to get real-world behavior for their ISP. What's the difference between chosing RSS and adjusting the parameters of engines to match real world behavior? It's the same thing, but you are still not experiencing the real scale of RSS  This is why I also play SSRSS sometimes (none of those god-awful long wait times to get a transfer window), which is a stock scaled RSS with another patch to bring engine performance back to real life behavior (the opposite of my rss patch). In the end it's all the same thing, so why fuss over the ISP value?

after a bit of digging all I really need to get SSTU to work with SMURFF is to make an arbitrary patch to divide the mass of tanks by 3. But yeah, I know that feeling of RSS's long transfer window. Lining up a even moonshot to test out a kickass moon rocket took a looooong time thanks to the inclination change. I have little experience with transferring to other planets, but judging by my moonshot impatience in RSS it'll be a pain in the ass ._.

The stuff you said and what I found is, as I said before, why I said bugger it and used 3.2x scale RSS (by patching SSRSS to use 24hr time and 3.2x stock scale.)

Debates over RSS aside, I found a bug where I can't adjust the number of SRB segments in sandbox mode. I'll do more testing tonight and see if the bug affects Career mode and Science mode as well.

Edited October 23, 2017 by T-10a

[Akira_R]

On 10/22/2017 at 12:04 AM, vossiewulf said:

*snip*

Oh well, if I had better reading comprehension you just explained the reason for the fuel-richness. And that makes sense, however then how do those Russian engines run with oxygen-rich preburners that power their turbines? I'd assume that exhaust would be extremely hot, unless the mass of unburned oxygen acted as a heat sink.

From my understanding the Russians were able to make oxidizer rich preburners because they had much better metallurgy than we did, basically they were able to make their turbines out of unique alloys that wouldn't turn to slag in those conditions, the exhaust was very hot and very very corrosive. The US wasn't able to make materials for the turbines and the seals that could stand up to those conditions at the time and so instead of investing more resources into the material science we stuck with fuel rich engines which were in many cases less efficient but much more reliable.

[Nightside]

@T-10a

It sounds like you have come to similar conclusion as myself, wanting to use SSTU in an RSS environment without committing to Realism Overhaul. 

Well, I am working on just that over here, generically resizing, resthrusting parts smurff-style.

It doesn’t work with SSTU now. I won’t be home till late tonight, but I should have some SSTU-specific updates tomorrow.

 

It is because of the high quality of mods such as sstu, and some of the planning mods like Basic DeltaV, etc that the extra time and planning required for RSS even sound fun.

Edited October 23, 2017 by Nightside
Trying to stay ontopic

[Shadowmage]

2 hours ago, T-10a said:

Debates over RSS aside, I found a bug where I can't adjust the number of SRB segments in sandbox mode. I'll do more testing tonight and see if the bug affects Career mode and Science mode as well.

If you can confirm the problem, please post an issue-ticket on the github tracker.  Seems like I had another report of a similar problem last week, but no issue ticket was opened (so I assumed the problem was resolved).

I do know that the unlocks were working in my career-testing game just after the update that added that functionality, so this might be another case of where 'part upgrades' have been disabled for that save entirely.

Edit:  Working through the models and texture setup for the LC tanks.  Was worrying a bit about the number of different textures (mostly AO bakes) that I would be needing.  Then I calculated out the number of unique part variants that would be available.  4mb in textures divided by 104 variants = ~40kb per-unique-part-variant.  Yeah, I'de say that is pretty efficient use of textures, considering stock might use ~2mb of textures for a single part.  It is slightly less efficient looking when you start adding in more texture sets -- until you consider that in stock each of the new texture sets would be the equivalent of adding 104 new unique parts.   For reference, the existing LC tanks use a total of ~12mb of textures, for a single texture set.  The new layout will only add <2mb per additional texture set (the diff/met/nrm maps are small and minimal, and only a single one is needed across all variants).

(not done yet on figuring out the texture layout; might be able to trim it down more, or it might end up needing more/larger textures....)

Edited October 23, 2017 by Shadowmage

[Jimbodiah]

3 hours ago, T-10a said:

Lining up a even moonshot to test out a kickass moon rocket took a looooong time thanks to the inclination change. I have little experience with transferring to other planets, but judging by my moonshot impatience in RSS it'll be a pain in the ass ._.

gheghe... you have to get into a 28.36 degree inclination when launching. To help out myself, I send up a probe first to 1000km and align that with the moon orbit. This gives a line in mapview in a LEO which is easier to line up when launching. When your launch site passes under the line, launch into either a +28.36 or -28.36 degrees and you can do an easy hohman transfer after getting a circular orbit. This is why I modified my launch site to be Alcantara (thanks to JoséEduardo) which is closest to the equator and gives you two nodes to launch into the Lunar orbit (stock Florida launch site barely touches one node).

Moonshots are no issue in RSS, you can timewarp until you intersect the lunar orbit line, but waiting for Mars etc to line up can take forever. "Better Time Warp" is almost a requirement for RSS, but it is broken since 1.3.1. And as I tend to use LS, I hate time-warping 2-3 years as I need to send several resupply missions to not let every stattion die out.

[tater]

A sorta replica of the thing I posted above:

For clarity a repost:

 

 

Edited October 23, 2017 by tater

[Jimbodiah]

Sorry for the OT, Mage... I'll try out the new releases soon

[RedParadize]

@Shadowmage

The new shader and tanks are truly magnificent. My compliment. If you are still working on the tanks, I would suggest adding some piping, cable and relay box on the tanks top/bottom that link to the main frame. It might be too much work but the option to have 2,4 or 8 tanks around the frame would be nice. Imagine how awesome it would look with instrument, legs and other stuff  filling the vacant space. 

I kinda stopped playing KSP for a while. I feel I done most of what the game was allowing. But looking at your stuff make me want to play again. I am gonna go hunt for some mission pack... I wish there was a SpaceX mission pack or something.

[tater]

Clearly we need some legs that look good, as well

 

Happily, some reprobate fixed legs and wheels so they actually work.