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

[tater]

Was messing around making a tethered Bigelow station... need to add persistent rotation, I guess.

 

[vossiewulf]

Did it not work? Looks pretty cool.

[vossiewulf]

On 10/7/2017 at 10:01 PM, vossiewulf said:

BTW Shadowmage and anyone else who decides to noodle around with SP, brush up on your blending modes. They're very important to the workflow in SP, being one of the primary parameters controlling the procedural materials and you need to understand them so you'll know what to use when and why. Otherwise you'll beat your head against some problem and then go ask a question in the forums and have some guy say like, why didn't you just use a decal and set it to multiply? And then you'd feel really stupid, not that I know anything about that, just saying it could theoretically happen.

Also you need to pay considerable, and I mean considerable, attention to the tutorials on properly setting up models for easy SP texturing. First, doesn't matter what material you assign to the model in the modeler, it will get blown away, so I just use flat standard materials roughly in the colors they'll be just for visual purposes in the modeler. And you want to minimize the number of materials, each one will turn into a big stack of RAM-eating layers. And in some cases as long as you're not under a tight poly budget, it makes sense to actually cut your model into separate elements based on your color pattern, it makes applying said basic pattern very quick to do and also allows individual control of those colors so you can churn out lots of color combinations as mentioned above.

And when you bake your maps in SP, remember to bake a materialID map, it gives you another tool to quickly select what you want and mask things for your color patterns. 

[tater]

8 hours ago, vossiewulf said:

Did it not work? Looks pretty cool.

My station? Yeah, it works, but with the persistent rotation it would stay spinning.

[Jimbodiah]

1.3.1 is out?  I'not updating untill all the mods support it. The update frequency from Squad is way too high.

[Shadowmage]

53 minutes ago, Jimbodiah said:

1.3.1 is out?  I'not updating untill all the mods support it. The update frequency from Squad is way too high.

Heh, that's actually where I'm at currently as well.  I have everything ready for the 1.3.1 update/release, but doing so would lock me out of my own current career/testing game (until all the other mods are updated anyway).

 

Will probably still push it out a bit later this afternoon though.  I'll just have to stash a copy of the current KSP 1.3.0 libs so that I can recompile a 1.3 version for myself...

 

@vossiewulf Thanks for the SP tips

So far I've managed to learn that:

• The SP interface is even more obtuse than Blenders (read: going to take a bit to learn)
• SP really hates my game-ready models; refuses to load them because 'the colliders don't have UV channels' (well, duh.. they're colliders) (easily solvable by exporting just the meshes for texturing)
• I'm going to have to do some customization / setup in order to get it working with my shaders and the rendering setup used by the recolorable parts
• Painting things in model-space is...weird... but could certainly have its advantages
• Lots more investigation to do before I'll know if it will be a good tool for my current needs and setup
• Could make UV unwraps much less painful; instead of worrying about unwrapping things to make it easy to texture... just unwrap it for minimal distortion and consistent scale, and call it good.
• Might require new models to make the best use of it -- the upcoming LC fuel tanks are probably going to be a good trial.

[Shadowmage]

Updated release is available; actually two releases -- a final 1.3.0 version, and a recompile for 1.3.1.  See the links for change-logs and downloads.  Quite a few balance tweaks to career mode and general career-oriented cleanup.

WARNING -- These releases do contain the removal of the StationCore integrated docking port options; it will have adverse effects on your existing craft that were using that feature.  If they were not using the feature, it should have no impact.  Does not have any impact on the ST-HUB line of parts.

1.3.0 link:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.6.38.142

1.3.1 link:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.7.38.143

[tater]

Will DL and test both versions tonight. 

I had a thought while trying to organize some SSTU craft files... would it be possible to have the back end of the Apollo SM as a mount? 

It's an important part of the look, and many of the notional craft that can be built based upon the Apollo CM (Eyes Turned Skywards, etc) look better with this option.

Certainly not critical, but I was looking at my alternate "block" CSMs last night, and I always wish they had that bit.

 

 

[Mike`]

Thanks for the new release and doing it both for 1.3 and 1.3.1, good idea.

As I've been building landers recently including one using the LC-5 pod, i noticed the large size of the latter, so i tried to do a rough volume comparison with the LC-3 pod. I estimated the LC-5 pod has roughly about 3.3 times the volume of the LC-3 - at that size, shouldn't it be both a bit heavier and have more kerbals onboard?

At equal kerbals per volume it would have about 10 kerbals, i guess.

Edited October 9, 2017 by Mike`

[vossiewulf]

7 hours ago, Shadowmage said:

Heh, that's actually where I'm at currently as well.  I have everything ready for the 1.3.1 update/release, but doing so would lock me out of my own current career/testing game (until all the other mods are updated anyway).

 

Will probably still push it out a bit later this afternoon though.  I'll just have to stash a copy of the current KSP 1.3.0 libs so that I can recompile a 1.3 version for myself...

 

@vossiewulf Thanks for the SP tips

So far I've managed to learn that:

• The SP interface is even more obtuse than Blenders (read: going to take a bit to learn)
• SP really hates my game-ready models; refuses to load them because 'the colliders don't have UV channels' (well, duh.. they're colliders) (easily solvable by exporting just the meshes for texturing)
• I'm going to have to do some customization / setup in order to get it working with my shaders and the rendering setup used by the recolorable parts
• Painting things in model-space is...weird... but could certainly have its advantages
• Lots more investigation to do before I'll know if it will be a good tool for my current needs and setup
• Could make UV unwraps much less painful; instead of worrying about unwrapping things to make it easy to texture... just unwrap it for minimal distortion and consistent scale, and call it good.
• Might require new models to make the best use of it -- the upcoming LC fuel tanks are probably going to be a good trial.

Yep, as noted the learning and setup curve are significant, and setting up models for SP texturing is a completely different output setup than you have been using. But there is an actual logic to the UI and workflow, and once you do get it you can do work very quickly. I remember flailing around working on it daily for a couple weeks before I started to get it, and by the third model I was able to do the work in a tiny fraction of the time the first one took. Best thing to do is just bury yourself in the tutorials and watch the key ones more than once.

For unwrapping, the best option is to not do it by hand- SP doesn't work well at all with unwraps where the sizes of objects are not normalized - i.e. you can't have one piece relatively larger than another, at least as far as I remember- I've not been using it for last several months so the info is out of the hot and warm DBs and is in cold storage, so I need to go run through it again to de-archive the knowledge. There are many tools, most are standalone, in the $40-$80 range now that could easily handle unwrapping models destined for KSP.

[Akira_R]

@Shadowmage So I am kinda new when it comes to working GitHub, is there a way to download a specific folder from a repository? I am trying to garb your optional patches folder but I don't want to download the whole SSTU repository and I am not seeing a way to do that....

[Shadowmage]

1 minute ago, Akira_R said:

@Shadowmage So I am kinda new when it comes to working GitHub, is there a way to download a specific folder from a repository? I am trying to garb your optional patches folder but I don't want to download the whole SSTU repository and I am not seeing a way to do that....

Same answer I gave last time that question was asked:

Not that I'm aware of. 

If/when the Optional Patches are in a usable state I will start to package and release them with the updates.  Until then about your only recourse will be to download the whole repository.  (This is intentional; the only people using the optional patches at this point should be those people who are actively working on/developing them; as such, they should already have the repository downloaded and setup for the ability to make commits/PRs)

 

[vossiewulf]

A minor bug, with the SRB-A when you mirror them in the editor and then fiddle the settings, all of the settings will be propagated to the mirrored instances, except the Variant control. If you want to switch variants, you have to do it individually to each one. Not sure what the intent is there as there's only one variant and it at least appears to just be shorter. A useful thing for that control to do would be to give you heavy, medium, and light versions; no change to the rocket other than setting the various settable controls to give the player a max power version, one in the middle, and something close to as small/light as it can be. That would let the player quickly get within the ballpark of what they want and have only minor tweaks to do.

Also my game died last night when the UI locked up in the editor trying to use the MFT-BDB Bluedog tank. If I remember what happened correctly, I tried to change the diameter, as soon as I did the VScale control turned to NaN and the right-click menu froze, I couldn't dismiss it. And although you can get a couple mod windows to pop, otherwise that dialog appears to be very modal and if you can't dismiss it, you're stuck. I will try it later tonight, even with a relatively fast machine my many-mod install takes like 10 minutes to load, doesn't make it easy to test such things, If I need to try it repeatedly I'll spawn off a clean install with BDB and SSTU and see if I can still reproduce.

Also there's still something clearly wrong with the fuel tank that grew to like 10m once in space - when I tried to use it in the editor it looked the same, no top or bottom, empty tube. I tossed it aside before trying to place it, I have a feeling it will break things too. I'll try to test that as well and get some info.

[Shadowmage]

41 minutes ago, vossiewulf said:

A minor bug, with the SRB-A when you mirror them in the editor and then fiddle the settings, all of the settings will be propagated to the mirrored instances, except the Variant control.

Thanks, noted, and should be fixed for the next release  ( https://github.com/shadowmage45/SSTULabs/issues/575 ).

 

42 minutes ago, vossiewulf said:

Also my game died last night when the UI locked up in the editor trying to use the MFT-BDB Bluedog tank.

I would suggest not using the SSTU expansion packs until they can be updated, or rather, only use them with the specific SSTU versions that they are built for.  (That is not one of my parts, comes from either Jose's or Jimbo's expansion packs).

^^^ Seems that those packs are likely what have been causing some of your problems.  As SSTU is ever-evolving, it is hard for the authors to keep their patch sets up to date with the latest plugin changes and model/config changes.

 

In general development news:

Hmmm... yes, been playing around with Substance Painter.  After you get some of the basic UI oddities figured out (and/or remapped), its not too hard to start doing (useful?) stuff. 

As the current WIP models are the upcoming LC fuel tanks I've been using them as a test-case for figuring out the changes to the modeling workflow and learn the texturing process.  I've made some... progress... in figuring the program out.

(geometry unfinished, textures are for learning purposes only and may not represent the finished parts)

(see spoiler for more images)

Spoiler

Non-weathered orange foam:

'Steel' tanks (think I remember seeing some of these in Fallout 4)

Rendered in blender with WIP PBR shader setup (reflections missing... this is about what it would look like in KSP)

 

Overall it is much easier to do the type of texturing work that I already do (mostly procedural); the program is seemingly built for it.  The big remaining questions are if I'll be able to get it to output textures that will work with the recoloring system / custom shader setup that I use.  I can always adjust the shaders to some degree, but regardless I will need SP to output textures that could be recolored.

[tater]

With a tank setup like the 8 tank, above, designing some landing legs that at the least have hardware that crosses the 2 metal bands might be useful, so the legs look like they are attached to something substantial.

[vossiewulf]

50 minutes ago, Shadowmage said:

Thanks, noted, and should be fixed for the next release  ( https://github.com/shadowmage45/SSTULabs/issues/575 ).

 

I would suggest not using the SSTU expansion packs until they can be updated, or rather, only use them with the specific SSTU versions that they are built for.  (That is not one of my parts, comes from either Jose's or Jimbo's expansion packs).

^^^ Seems that those packs are likely what have been causing some of your problems.  As SSTU is ever-evolving, it is hard for the authors to keep their patch sets up to date with the latest plugin changes and model/config changes.

 

In general development news:

Hmmm... yes, been playing around with Substance Painter.  After you get some of the basic UI oddities figured out (and/or remapped), its not too hard to start doing (useful?) stuff. 

As the current WIP models are the upcoming LC fuel tanks I've been using them as a test-case for figuring out the changes to the modeling workflow and learn the texturing process.  I've made some... progress... in figuring the program out.

(geometry unfinished, textures are for learning purposes only and may not represent the finished parts)

(see spoiler for more images)

  Hide contents

Non-weathered orange foam:

'Steel' tanks (think I remember seeing some of these in Fallout 4)

Rendered in blender with WIP PBR shader setup (reflections missing... this is about what it would look like in KSP)

 

Overall it is much easier to do the type of texturing work that I already do (mostly procedural); the program is seemingly built for it.  The big remaining questions are if I'll be able to get it to output textures that will work with the recoloring system / custom shader setup that I use.  I can always adjust the shaders to some degree, but regardless I will need SP to output textures that could be recolored.

There ya go.

Yes, SP is in essence a procedural texturing system, all materials are procedural to some degree, and usually to a great degree as you see from the number of controls available on simple materials and smart materials get even more complex. And you probably haven't fiddled with the filters yet, that's a whole other way to procedurally generate effects.

A good way to get the basics of materials and surfaces is to just cover something in the basic paint material, and then start playing with the surface parameters and the metal/roughness, especially the scale on your generators, you can get wildly different results by controlling the scale of the effects. The paint material has all those basic controls and not much else, and it's really easy to see the changes as you mess around with the controls, and you'll very quickly begin to understand how to get anything from a smooth, shiny, slightly rippled surface to rough paint to dead flat very rough surface. 

However, SP is a tool where although it's fun messing around with materials, you can get much more done by downloading free ones and there are also people selling material collections, some of which are very much worth the money. The fact is they rapidly get super-complex and you're never going to understand enough to be effective unless you're willing to spend lots of time learning how their models work and messing around in Substance Designer. So you flesh out your material library until you have multiple options for all the types you're going to use, and at the same time make lots of alphas of the kind of surface details you need, things like interstage ribs can just be alphas you stamp into the normal map with a few clicks. I don't like bleeping over something like that but I spent some time with Designer and the people making materials are just uber geeks and you need to be very close to a physicist specializing in EM radiation to even follow the discussions. Once upon a time we did everything, now the field has started to develop a number of specialties where the complexities rule out learning much more than one.

 

[Shadowmage]

Hmm....

Left = SSTU-PBR Shader (using reflection probes and most of the Unity Standard Shader pipeline; going to rework to use cubemap for reflections)
Center = Unity 5 Standard Shader
Right = Unity 4 / Legacy Reflective Shader

Yes, I've started working on a proper reflection-enabled shader setup.  As reflection probes are 'broken' in KSP, I'm forced to rework things to use a legacy cube-map setup.  This new shader will be needed in order to support materials created with Substance Painter, as its 'Unity 4 / Specular' texture outputs are terribly broken (rather most of the materials don't support legacy shader setups).  After I get the new shader working, I'll still have to 'rework' it a bit further in order to support the recoloring system (some support will also need to be done in the exported textures).

[vossiewulf]

1 hour ago, Shadowmage said:

Hmm....

Left = SSTU-PBR Shader (using reflection probes and most of the Unity Standard Shader pipeline; going to rework to use cubemap for reflections)
Center = Unity 5 Standard Shader
Right = Unity 4 / Legacy Reflective Shader

Yes, I've started working on a proper reflection-enabled shader setup.  As reflection probes are 'broken' in KSP, I'm forced to rework things to use a legacy cube-map setup.  This new shader will be needed in order to support materials created with Substance Painter, as its 'Unity 4 / Specular' texture outputs are terribly broken (rather most of the materials don't support legacy shader setups).  After I get the new shader working, I'll still have to 'rework' it a bit further in order to support the recoloring system (some support will also need to be done in the exported textures).

That sounds like you've almost worked out a new workflow with SP? As for the shaders, little bit of a difference between 5 and your PBR, primarily in the glossiness, otherwise very close. How does the recoloring work? One way I've seen that done is the actual maps applied to the objects have only a series of pure color values applied, and the recolor logic knows (e.g.) for material 1 it alters any pixel with a hue of 255,0,0.

[Shadowmage]

1 hour ago, vossiewulf said:

That sounds like you've almost worked out a new workflow with SP?

I've learned enough to know that the program will be usable for my purposes (and quite good for it too).  Still quite a bit to learn, and a bit of workflow to figure out.  But more importantly, I need to know if I can even use the textures that it creates (hence the work on PBR) -- if I can't use the textures in KSP, no reason to continue learning.

 

1 hour ago, vossiewulf said:

As for the shaders, little bit of a difference between 5 and your PBR, primarily in the glossiness, otherwise very close.

Yeah, I'm still using most of the Unity Standard Shader pipeline in the above example, so it should be (nearly) identical (minus whatever stuff I accidentally removed due to their weird compiler-directive-driven code setup and not knowing what the active environment is).  Next up will be adapting it to use standard/legacy lighting (non-global-illumination) alongside a cube-map for reflections.  The end result will likely have quite a few visual differences as compared to the Unity Standard/PBR shaders -- mostly due to the lack of GI and the use of cubemaps rather than reflection probes (I'll have to hack around the lack of GI somehow).

 

1 hour ago, vossiewulf said:

How does the recoloring work?

Under the current system -- the diffuse and specular textures have a base of flat gray (128,128,128), with details being either highlights or shadows (so basically grayscale), which is then used in the shader as an offset-additive-detail channel on top of a user-selected color.  So essentially the existing diffuse/specular textures are 'detail' textures, with the base color of the material set by the user.  What portions each recolor selection is responsible for is determined by an RGB mask texture; each color in the mask represents 1 recolor 'selection'.

Basically -- outputColor = userColor + (diffuse * 2 - 1)  //with a bunch of extra code to handle portions that are not masked / to select the proper user-color from the 3 selections based on the mask setup.

[vossiewulf]

29 minutes ago, Shadowmage said:

I've learned enough to know that the program will be usable for my purposes (and quite good for it too).  Still quite a bit to learn, and a bit of workflow to figure out.  But more importantly, I need to know if I can even use the textures that it creates (hence the work on PBR) -- if I can't use the textures in KSP, no reason to continue learning.

Awesome! Really glad you think it's going to work for you, I think with a bit more learning and some fleshing out of your material library, you're going to wonder how you ever managed without it, it hopefully will accelerate your process quite a bit and that means more cool parts for KSP with more cool functions and textures.

 

35 minutes ago, Shadowmage said:

Under the current system -- the diffuse and specular textures have a base of flat gray (128,128,128), with details being either highlights or shadows (so basically grayscale), which is then used in the shader as an offset-additive-detail channel on top of a user-selected color.  So essentially the existing diffuse/specular textures are 'detail' textures, with the base color of the material set by the user. 

Yep, similar to what I've seen but this is reasonably flexible. Your base maps sound like basically high-res AO maps, if you haven't already look up the function that allows you to isolate a map on the model, so you can see each of the maps you've baked standalone. First it's a useful way to check your baked textures and to also see certain things about the model, one of them should be Ambient Occlusion. I have to think the AO map has to be real close to what you need for you base maps, or at least the process of creating those maps would involve blending down the AO map into it. Start with a simple flat drawing of the details, burn the AO map into it, should have grayscale version of your drawing with all the correct lighting highlights and shadows.

[vossiewulf]

Also, a request that should be quick to do - can you put an arrow or some other indicator on your probe core that shows which way it's facing? At the moment it seems completely symmetrical, no idea if it's aligned for polar or equatorial orbit. Unless there's something there already and I'm just missing it.

[Jimbodiah]

[T-10a]

Spoiler

@PART[SSTU-ST-COS-ATV-S|SSTU-ST-COS-ATV-M|SSTU-ST-COS-STORAGE-XS|SSTU-ST-COS-STORAGE-S|SSTU-ST-COS-STORAGE-M|SSTU-ST-COS-STORAGE-LSSTU-SC-TANK-MFT-A|SSTU-SC-TANK-MFT-B|SSTU-SC-TANK-MFT-L]
{
    @MODULE[SSTUVolumeContainer]
    {
        @CONTAINER,0
        {
            resource = LqdMethane
        }
    }
}
SSTU_RESOURCEVOLUME
{
    name = LqdMethane
    volume = 1
}
@SSTU_RESOURCESET
{
    name = Methalox
    resource = LqdMethane
}
 

I'm trying to add a resource to containers ingame (LqdMethane to power my custom RD-0162 engine), but I'm a bit stuck on how to add it to tanks as well as let it appear in the Tank contents slider so it has the correct propellant ratios ready to go in the MFT (3.5:1 or 7:2)

Edited October 12, 2017 by T-10a

[Shadowmage]

4 hours ago, T-10a said:

  Hide contents

@PART[SSTU-ST-COS-ATV-S|SSTU-ST-COS-ATV-M|SSTU-ST-COS-STORAGE-XS|SSTU-ST-COS-STORAGE-S|SSTU-ST-COS-STORAGE-M|SSTU-ST-COS-STORAGE-LSSTU-SC-TANK-MFT-A|SSTU-SC-TANK-MFT-B|SSTU-SC-TANK-MFT-L]
{
    @MODULE[SSTUVolumeContainer]
    {
        @CONTAINER,0
        {
            resource = LqdMethane
        }
    }
}
SSTU_RESOURCEVOLUME
{
    name = LqdMethane
    volume = 1
}
@SSTU_RESOURCESET
{
    name = Methalox
    resource = LqdMethane
}
 

I'm trying to add a resource to containers ingame (LqdMethane to power my custom RD-0162 engine), but I'm a bit stuck on how to add it to tanks as well as let it appear in the Tank contents slider so it has the correct propellant ratios ready to go in the MFT (3.5:1 or 7:2)

Very close.  You can remove the RESOURCESET -- those are simply to make it easier to add lots of resources to a container at one time.

The bit you are missing would be (add this config node to a new file / as a root node in an existing file):

SSTU_FUELTYPE
{
	name = Methalox
	RESOURCE
	{
		resource = LqdMethane
		ratio = 9
	}
	RESOURCE
	{
		resource = Oxidizer
		ratio = 11
	}
}

That is what adds it to the fuel-type slider.  If those resources are found on the part, it should show up in the slider.  Set up the ratios properly (7:2 as you listed in your post), and it should be good to go (must be an integer ratio; decimal values are unsupported).

 

14 hours ago, vossiewulf said:

Also, a request that should be quick to do - can you put an arrow or some other indicator on your probe core that shows which way it's facing? At the moment it seems completely symmetrical, no idea if it's aligned for polar or equatorial orbit. Unless there's something there already and I'm just missing it.

Good point (ditto on the decoupler).  Probably not as simple or quick as you might think though   Those meshes are generated procedurally (completely from code), and as such there is no way to add any differentiation to the model itself (only cylinder/cone shapes are supported by the current generation code).  However, I might be able to add something to the texture that would tell you what vertical side is 'up' and which horizontal side is 'front'.  The alternative would be to move those parts to use discrete models (with scaling and model-switch support); which is already 'planned', but awaiting time to make the new models/textures for it.

-- https://github.com/shadowmage45/SSTULabs/issues/577

 

[Jimbodiah]

Could you make the top color red or something to see that that is the top side? This way you do not need to change the textures of the sides.