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

[Shadowmage]

4 minutes ago, StickyScissors said:

@Shadowmage Would it be possible to make a radially attachable, multi-RCS-port ring that sort of wraps around fuel tanks when placed, to cut down on parts further? Imagine the modular command probe core but with 4 RCS ports evenly spaced around the outside, but it is placed radially rather than on a node.

Jeez, this is difficult to convey through text.

Here's a sweet MSPaint gif that hopefully gets what i'm thinking about across alightly better

 

 

Thanks for the graphics

I've actually given this quite a bit of thought in the past.  Yes it would be doable.  The problem comes down to surface attach joints and how they wobble (around the attach point rather than the center of the parent part).

Basically when you surface attach something its joint to the part it is attached to is -on the surface- of the parent part.  So if it wobbles, it will oscillate around that point rather than in the center of the parent part where it should logically wobble for a part setup like this.  This can be seen (albeit a different manifestation of the same problem) when using the RBDC when KJR is not present;  the parts attached to the RBDC rotate around the surface-attach point rather than in the center of the tank.

What this means in practice is that the RCS port(s) that are closest to the surface attach point would be most stable/move the least (just like a stand-alone RCS port), while those on the opposite side of the tank would have proportionally greater displacement whenever the joint wobbled (possibly enough to be noticeable; would highly depend on the thrust output from the ports).  Any such displacement/wobbling would result in off-axis thrust and/or an unbalanced RCS setup.

Another 'problem' facing this setup is KSPs drag calculations -- pretty sure the stock code would put the entire drag for the part as a vector centered on the attachment point rather than the centroid of the actual part/bounds, thus the parts would be extremely unstable in any kind of aero setup (in stock at least... FAR should not suffer those problems).

And one final problem that this setup would face -- the colliders on many parts are not quite consistent enough to allow for a single wrap-around part to center itself perfectly around the tank.  The tank may have render bounds of 2.5m diameter, but the colliders may be only 2.48m (due to being 12 sided rather than 24 sided), and thus the RCS/engine ring would be offset by 0.02m, resulting in off-balanced RCS/thrust.

 

I've contemplated doing such for both RCS and separation motors as I think they could both benefit from the same type of setup.  However they would both suffer from the joint problem outlined above, with the higher the thrust output the more noticeable the problem would be.

Perhaps I'll put together a couple of non-modular/manually welded parts for testing of the concept.  The joint wobble/displacement might not be as bad as I'm thinking, and might not be noticeable on RCS ports at all (and almost certainly should be fine with KJR, at least for RCS ports).  Would also allow for testing of the drag setup and for model/collider offsets to see how bad they would be.

I wouldn't get your hopes up though.  I don't think I'll be able to solve some of those problems (drag and collider diameter differences).

[RedParadize]

2 hours ago, Shadowmage said:

Do you think there would be any desire to have these released as a stand-alone 'shader pack'?  The lineup could easily be expanded to include alternates to the other KSP shaders (non-bump-mapped types, etc)

I believe there is many many of the current SSTU feature that would interest other modder. Just saying. ShotgunNinja said good stuff about your code.

@StickyScissors @Shadowmage Regarding the RCS thing. Would it not be more simple to have a stackable ring with RCS? I would gladly take that. It could simply repurpose your stack decoupler but with RCS around it.

Edit, if the probe/decoupler style RCS ring would allow surface attachment, but from its center. And then be centred manually. Would it not solve the problem you mentioned?

Edited September 9, 2016 by RedParadize

[StickyScissors]

2 minutes ago, Shadowmage said:

Perhaps I'll put together a couple of non-modular/manually welded parts for testing of the concept.  The joint wobble/displacement might not be as bad as I'm thinking, and might not be noticeable on RCS ports at all (and almost certainly should be fine with KJR, at least for RCS ports).  Would also allow for testing of the drag setup and for model/collider offsets to see how bad they would be.

Hmm, ok, you make some good points. If the radially atached one doesn't work out, would it be easier/more feasible to do one that is node attached to the ends of parts?

Although, that would mean that you couldn't use the tank noses and/or mounts properly due to the nose node being taken and the RCS ring being shifted wherever the user desires.

[blowfish]

1 hour ago, Shadowmage said:

@blowfish

Been doing some thinking on the custom shader setup, and I'm pretty sure I've figured out a few new shaders that I could make use of.  Not 100% set on their setup (channels per texture/etc, single UV map or multiple UV maps), but this is what I've come up with so far:

1.) Diffuse (RGB) - Specular (RBG) AO (A) - Bump/NRM   (AO in alpha channel of spec texture; full color specular texture)
2.) Diffuse (RGB) alpha (A) - Specular (RBG) AO (A) - Bump/NRM    (Alpha in A channel of diffuse, AO in alpha channel of spec texture; full color specular texture)
3.) Diffuse (RGB) alpha (A) - Emissive (RGB)  (Full-color emissive with alpha support - for 'glow in the dark' decals or whatnot)

Mostly the features that I'm needing are a separate channel for AO (can be a single channel), full-color specular, and some sort of emissive-shader-with-alpha support.

Do you think there would be any desire to have these released as a stand-alone 'shader pack'?  The lineup could easily be expanded to include alternates to the other KSP shaders (non-bump-mapped types, etc)

I'd say just implement what you need for now, and worry about extracting/generalizing if someone specifically needs it.

Putting the AO into the specular map seems odd to me - wouldn't you want the specular map to match the diffuse map somewhat? (whereas the AO map depends more on the geometry)?

[RedParadize]

27 minutes ago, blowfish said:

Putting the AO into the specular map seems odd to me - wouldn't you want the specular map to match the diffuse map somewhat? (whereas the AO map depends more on the geometry)?

I don't think its what he said. AO is monochrome. So one of the 4 channel present, in this case the alpha.

Edited September 9, 2016 by RedParadize

[blowfish]

1 minute ago, RedParadize said:

I don't think its what he said. AO is monochrome. So one of the 4 channel present, in this case the alpha.

Yes, a separate channel.  But my point was that it seems like you might want to change the specular and AO maps independently of each other, which is not possible if they're in the same file.

[Shadowmage]

8 minutes ago, blowfish said:

I'd say just implement what you need for now, and worry about extracting/generalizing if someone specifically needs it.

Putting the AO into the specular map seems odd to me - wouldn't you want the specular map to match the diffuse map somewhat? (whereas the AO map depends more on the geometry)?

Noted... and yeah, I should probably actually make them before thinking about making them generically usable.

 

Specular / AO --  A single UV map would be used for both the diffuse and specular maps.  The AO in the alpha of the specular texture would use the same UV mapping as both the diffuse and specular textures.  So all of them would match up with the diffuse texture to some extent / all would be based on the same UV mapping.  The main changes compared to existing KSP shaders is that the AO texture could be disabled at the shader level, and the allowance of full-color specular setups (for example on solar panels, where the panels may have a different specular color from the frame... gold panels vs. silver frame; impossible with current KSP shaders without splitting the meshes up).

Essentially I'm trying to add full-color specular and optional AO support.  From those requirements I'm left with two textures with unused alpha channels (Diffuse is RGB only, specular is RGB only, both would have unused alpha channels).  I can either slot the AO into the alpha on the diffuse texture, or into the alpha on the specular texture; either way would use the same UV mapping for all textures (diff/spec/nrm).  Actual alpha support seemed more logical to put with the diffuse texture (so it is a proper ARGB/RGBA texture), and AO being related to shading seemed logical to me to put with the specular texture.

The AO could even be a third (fourth if normal mapped) texture, but that seems a bit inefficient (3rd/4th texture slot in the shader, additional texture sampling in the code, and 3 unused channels in the AO texture as it is a simple grayscale texture; I have not found any specialized DXT-grayscale format, all of them seem encode 3 or 4 channels).  Although keeping the AO as a completely separate texture does open up a few interesting use options as far as the modular parts are concerned (use of different AO bakes depending upon what modules are setup/present)... however that comes with its own set of problems that I've not yet put much thought into.

If you have suggestions though as to other texture/channel setups that might work well I would love to hear them (or other thoughts on the shader subject in general).  Have merely outlined a couple of the concepts I had, they are by no means final.

[RedParadize]

@blowfishIf the specular map is read as black = no specular. Then AO and Spec can be controlled separately as you wont need a alpha for the spec. A bit like PNG alpha if you like.

[Shadowmage]

16 minutes ago, blowfish said:

Yes, a separate channel.  But my point was that it seems like you might want to change the specular and AO maps independently of each other, which is not possible if they're in the same file.

Now that I've thought on it a bit more -- that is an excellent point.

If AO was in the same texture as specular you would need multiple copies of a specular texture, one for each AO setup times the number of specular variants (probably only one, but still could be a problem).  For my specific use-case though, I think might still be okay, as I'de mostly be using it to enable/disable the AO entirely rather than switch between AO maps... but is still a valid concern.

I'll certainly have to give it some more thought though.  -Might- start on a bit of it this weekend (after the next release)... will try out a few things to see what works best for memory use and workflow.

 

 

On the note of 'previews of the next release' -- tentative layout of the handrails for the COS modules (texture set to black so they can actually be seen in the images; they'll likely be either gray/silver or yellow when finished).  Debating on if I should put a ring or two around the center areas of the larger modules... don't think it is really necessary, but I might try it out to see what it looks like.  And yes, they will all have proper ladder colliders on them and actually be usable as ladders.  Might also add some handrails to the '2-1 dome' adapter model (yes, ladders and hatches can be added to adapters, no need for any special module setup for those).

 

[RedParadize]

One comment about the handrail. I think their overal size are ok, about 1/2 of a kerbal high right? If they would be just a bit smaller the hab would look bigger. Also. I think that a lower profile would look better and preserve the apparent size. As they are right now I think a Kerbal could probably place his full arm under it.

Edit, After looking reference. Their size are about right. Profile is a bit too high but it have more to do with the weird proportion of kerbals.

I just noticed that handrail and panel were always not aligned or centred. Its looks weird, but its like that for some module in real life. Oh well...

Edited September 9, 2016 by RedParadize

[blowfish]

1 hour ago, RedParadize said:

@blowfishIf the specular map is read as black = no specular. Then AO and Spec can be controlled separately as you wont need a alpha for the spec. A bit like PNG alpha if you like.

The shader takes a fixed number of texture inputs and applies them.  If you have the specular and AO on the same texture, you can't change the specular without changing the AO, or the opposite.  You can disable one or the other, sure.

[RedParadize]

18 minutes ago, blowfish said:

The shader takes a fixed number of texture inputs and applies them.  If you have the specular and AO on the same texture, you can't change the specular without changing the AO, or the opposite.  You can disable one or the other, sure.

Shader can't control channel individually in unity? That's a shame. I didn't play much with game engine but in maya and nuke its basic stuff.

Edited September 9, 2016 by RedParadize

[Shadowmage]

5 minutes ago, RedParadize said:

Shader can't control channel individually in unity? That's a shame. I didn't play much with game engine but in maya and nuke its basic stuff.

Yes it can control individual channels -- the part @blowfish is getting at is the texture.  If the shader is setup to use the alpha channel from the specular mask as an AO, then an entirely new texture would be needed just to have a different alpha channel in it.

 

However, after doing a bit of.. research... I'm fairly certain I'm just going to use a stand-alone grayscale texture for the AO bake.  It'll be another texture-slot on the shader, but it will decouple the AO from the specular texture and allow for an easier overall workflow (don't have to deal with masking things), as well as saving a bit of space in the specular texture by not forcing it to have an alpha channel (which in DXT compression nearly doubles texture size).

So, from a bit of research it looks like two RGB textures compressed with DXT1 would be similar in size to a single ARGB texture compressed with DXT5.

[RedParadize]

I don't see the problem.

AO is Mono. Specular don't need alpha, unless if you want a black specular spot. So Specular alpha is the color itself. R0 G0 B0 = no spec. R128 G128 B128 = 50% white spec.

What you could use the alpha for is to control specular eccentricity/cosine power trough texture. That would be a good thing since metallic foil would have a low Eccentricity/Cosine power and textile a fairly high one.

But again last time I played with a game engine was 8 years ago. I don't know much about the subject.

Edited September 9, 2016 by RedParadize

[blowfish]

9 minutes ago, RedParadize said:

I don't see the problem.

AO is Mono. Specular don't need alpha, unless if you want a black specular spot. So Specular alpha is the color itself. R0 G0 B0 = no spec. R128 G128 B128 = 50% white spec.

What you could use the alpha for is to control specular eccentricity/cosine power trough texture. That would be a good thing since metallic foil would have a low Eccentricity/Cosine power and textile a fairly high one.

But again last time I played with a game engine was 8 years ago. I don't know much about the subject.

Yes, you can apply the RGB as specular and the alpha channel as AO.  That's all fine.  But what happens when you want to switch (dynamically, in-game) to a different AO map?  The way the shaders work you can really only swap out the entire texture, which in this case would include all the specular and AO information.  You'd have to have another texture file with the same RGB channels but a different alpha channel.

[RedParadize]

Just now, blowfish said:

Yes, you can apply the RGB as specular and the alpha channel as AO.  That's all fine.  But what happens when you want to switch (dynamically, in-game) to a different AO map?  The way the shaders work you can really only swap out the entire texture, which in this case would include all the specular and AO information.  You'd have to have another texture file with the same RGB channels but a different alpha channel.

Ah! Now I see your point. Sorry I am sometimes slow. That problem is also true the texture switching... Outch, I suddenly realise that the number of possible mesh and various texture combination will be really high.

[Shadowmage]

So... I got bored/needed a bit of a break from modeling/wanted to investigate something new (always scary). 

The 'Bumped ColorSpecular AO' shader is now a thing, and going through cleanup/revision/feature-adding passes on the shader code.

The diffuse texture on that is pretty much flat grey.  The red/blue highlights are from the color specular shading.  The dark areas (band on the top, black areas in the ports on the side, shading around the ports) is all part of a separate AO map texture. 

Fun times.  Now I need to figure out how to use different UV slots (in case I want different UV mapping for the AO).  Well, don't need to... but I think it would be a nice option to have.

Also will need to figure out how to actually load the shaders into KSP... but there are a few other mods with custom shaders that I can check into to see how it is done, so probably won't be too hard to figure out.

No, probably won't have any of this included in this weekends release, mostly working on concept validation and planning out the new workflow.

[RedParadize]

Impressive. Damn impressive. Squad shoud hire you. 

Edit

Also will need to figure out how to actually load the shaders into KSP... but there are a few other mods with custom shaders that I can check into to see how it is done, so probably won't be too hard to figure out.

Oh I should have read more carefully. There is probably a reason why there is not much custom shader like this in KSP. 

Edited September 10, 2016 by RedParadize

[StickyScissors]

Hearing from a few people that wheels are still having a terrific amount of issues in the experimental versions. Random explosions, slipperiness and there is still waaaay too much front gear bouncing on touchdown of aircraft. What a shame :/

Edited September 10, 2016 by StickyScissors

[Theysen]

1 hour ago, StickyScissors said:

Hearing from a few people that wheels are still having a terrific amount of issues in the experimental versions. Random explosions, slipperiness and there is still waaaay too much front gear bouncing on touchdown of aircraft. What a shame :/

Is that so? Parts of the stream that I saw had really good wheel physics and no random explosions, no sliding and anomalies. Other parts of the stream involved hacking gravity and landing at 100m/s nose first, don't know what is to be expected from kerbal wheels to endure  

 

I'd say we better wait for public experimentals and mod devs like @Shadowmage can put their findings into feedback and give a realistic opinion on it. 

[Shadowmage]

This weekends update will be available sometime tomorrow morning, hopefully.  Taking a bit more time to do more texture and config work on a few parts; would rather take the time now and have those bits finished for this release.

[StickyScissors]

@Shadowmage Found an issue with station parts and symmetry that i have somehow managed to not find until now.

Example jif: 

 

-

Relevant part of output file:

Spoiler

SSTU-ST-COS-HAB-M added to ship - part count: 9
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
  at System.Collections.Generic.List`1[PartModule].get_Item (Int32 index) [0x00000] in <filename unknown>:0
  at PartModuleList.get_Item (Int32 index) [0x00000] in <filename unknown>:0
  at EditorLogic.CopyActionGroups (.Part sPart, .Part cPart) [0x00000] in <filename unknown>:0
  at EditorLogic.attachSymParts (.Attachment[] cAttaches) [0x00000] in <filename unknown>:0
  at EditorLogic.<SetupFSM>m__101 () [0x00000] in <filename unknown>:0
  at KerbalFSM.RunEvent (.KFSMEvent evt) [0x00000] in <filename unknown>:0
  at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00000] in <filename unknown>:0
  at KerbalFSM.UpdateFSM () [0x00000] in <filename unknown>:0
  at EditorLogic.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Notes:

-This issue only happens with parts that come with swapable ports right out of the part menu, such as the ST-COS-HAB-L.

-If you place, for example, the ST-COS-HAB-L down without symmetry, set TDock and BDock to Mount-None, then place it down with any symmetry amount, it will work fine. 

-It's kinda annoying trying to build a wet-lab concept with symmetry issues

 

 

 

[pap1723]

SSTU is officially supported by the Historical Progression Tech Tree!

[Pappystein]

On 9/9/2016 at 1:21 PM, Shadowmage said:

Thanks for the graphics

I've actually given this quite a bit of thought in the past.  Yes it would be doable.  The problem comes down to surface attach joints and how they wobble (around the attach point rather than the center of the parent part).

Basically when you surface attach something its joint to the part it is attached to is -on the surface- of the parent part.  So if it wobbles, it will oscillate around that point rather than in the center of the parent part where it should logically wobble for a part setup like this.  This can be seen (albeit a different manifestation of the same problem) when using the RBDC when KJR is not present;  the parts attached to the RBDC rotate around the surface-attach point rather than in the center of the tank.

<SNIP>

I wouldn't get your hopes up though.  I don't think I'll be able to solve some of those problems (drag and collider diameter differences).

Actually, I think @NecroBones solved this issue with his radial SAS module in his SpaceY mod.    It goes on in Symmetry 2. Drag and Wobble forces will cancel each other out because the same drag/wobble is happening exactly 180 degrees out of phase (IE on the other side of your Rocket.)  

Applying his methodology, assuming a quarter circle with an RCS thrust point at each end, and the attachment halfway across the arc. You will have reduced your RCS part count by half and you are ALMOST as accurate (in lack of wobble) as you were with the standard parts.  

But I agree with others that a modified stack mounted probe core is the better choice because then everything is centered no matter what.    can you swap node sizes out when you resize a part (for larger torque/drag resiliency on larger stack RCS modules?)

On 9/7/2016 at 10:44 AM, Shadowmage said:

Hmm.. that may be a bug with the zero-boil-off tanks then;  there should be zero loss as long as you have sufficient EC generation.  Was the time spent during time-warp with the vessel focused, or at the space/another vessel?

 

Fuel tanks -- they should, by default, have the same impact tolerance and heat stats as stock fuel tanks.  Note that some of the tank modifiers reduce these values; such as the 'lightweight' tank which reduces both impact tolerance and max heat stats.

There might however be some bugs with either the thermal values for the part or with the drag cubes that are causing incorrect thermal calcs (will need to dig back in on how stock calculates thermal mass/skin mass)

I was out of SOI of the station for much of that time (6 weeks game time.) waiting for my probe to get to it's next burn point and time warp was a factor.

I have run 3 rockets now with ZBO tanks, each keeps spamming in the right click Tweakable menus a temporary loss measured in what I think are µl.

I am checking these during my burn to orbit or while ON station.

NOW,  Not all of my tanks are ZBO but the non ZBO tanks are not in the same stage and there is no fuel flow that should be happening.

 

Re The tank fragility,   I am sick so this weekend when I am up I will play with things further.

 

 

[123nick]

3 hours ago, StickyScissors said:

@Shadowmage Found an issue with station parts and symmetry that i have somehow managed to not find until now.

Example jif: 

 

-

Relevant part of output file:

  Reveal hidden contents

SSTU-ST-COS-HAB-M added to ship - part count: 9
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
  at System.Collections.Generic.List`1[PartModule].get_Item (Int32 index) [0x00000] in <filename unknown>:0
  at PartModuleList.get_Item (Int32 index) [0x00000] in <filename unknown>:0
  at EditorLogic.CopyActionGroups (.Part sPart, .Part cPart) [0x00000] in <filename unknown>:0
  at EditorLogic.attachSymParts (.Attachment[] cAttaches) [0x00000] in <filename unknown>:0
  at EditorLogic.<SetupFSM>m__101 () [0x00000] in <filename unknown>:0
  at KerbalFSM.RunEvent (.KFSMEvent evt) [0x00000] in <filename unknown>:0
  at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00000] in <filename unknown>:0
  at KerbalFSM.UpdateFSM () [0x00000] in <filename unknown>:0
  at EditorLogic.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Notes:

-This issue only happens with parts that come with swapable ports right out of the part menu, such as the ST-COS-HAB-L.

-If you place, for example, the ST-COS-HAB-L down without symmetry, set TDock and BDock to Mount-None, then place it down with any symmetry amount, it will work fine. 

-It's kinda annoying trying to build a wet-lab concept with symmetry issues

 

 

 

isnt it pronounced .Gif ? with a hard G ?