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

[Electrocutor]

Initial findings for 1.4.1:

DirectX 9 -  Somewhat unstable; infrequent crashes; micro-stutter
DirectX 11 - No VAB icons, highly unstable: fairly constant crashing switching between scenes.
DirectX 12 - Same as dx11
OpenGL Legacy - Stable; micro-stutter
OpenGL Core - No issues detected thus far; better performance than GL Classic; currently recommended mode
Vulkan - Not compiled with compatibility

.\KSP_x64.exe -force-glcore

 

Edited March 14, 2018 by Electrocutor

[tater]

So I got the DLC, and messed around.

The MEM is kinda cool... but man, I forgot how trained I am to make rockets now. I made the equiv of a petal adapter, and forgot to put decouplers inside.  Oops. I did my TMI burn, blew the panels, and could not disconnect the CSM, lol. I was right clicking all over the thing, completely baffled. LOL.

It's just as well, I forgot parachutes (I put a docking port on it!), because why would I ugly up a capsule with radial chutes?

[Jimbodiah]

I had the same issue with the heatshield where it did not seperate the stage below it but jetisson the shield instead. Thank god for alt-f12

[RedParadize]

15 hours ago, tater said:

So I got the DLC, and messed around.

The MEM is kinda cool... but man, I forgot how trained I am to make rockets now. I made the equiv of a petal adapter, and forgot to put decouplers inside.  Oops. I did my TMI burn, blew the panels, and could not disconnect the CSM, lol. I was right clicking all over the thing, completely baffled. LOL.

It's just as well, I forgot parachutes (I put a docking port on it!), because why would I ugly up a capsule with radial chutes?

I am not doing this, I will wait for SSTU and other mods before updating.

[tater]

1 minute ago, RedParadize said:

I am not doing this, I will wait for SSTU and other mods before updating.

LOL.

It;s actually good to play the stock game from time to time. Every time I do, my appreciation for @Shadowmage and other modders increases.

[T-10a]

I tried playing with BDB and while the lego-ish nature of the parts feel great (they are much nicer than the US DLC parts IMO), it feels so weird to have many different parts to make a Kane CSM (a docking port, chute mount, 3 separate chutes, capsule, and heatshield for the CM alone!), and not being able to paint those parts feel weird as well.

No offense to CobaltWolf tho, they're unbelievably well done parts!

[Jimbodiah]

They actually added wolfy's gemini capsule to KSP I think

[Shadowmage]

On 3/14/2018 at 2:00 PM, Electrocutor said:

Initial findings for 1.4.1:

DirectX 9 -  Somewhat unstable; infrequent crashes; micro-stutter
DirectX 11 - No VAB icons, highly unstable: fairly constant crashing switching between scenes.
DirectX 12 - Same as dx11
OpenGL Legacy - Stable; micro-stutter
OpenGL Core - No issues detected thus far; better performance than GL Classic; currently recommended mode
Vulkan - Not compiled with compatibility

.\KSP_x64.exe -force-glcore

 

Strangely (but not surprisingly), this is what I am seeing as well.  1.4.1 - DX9/DX11 have new issues that didn't exist in 1.3.1 regarding reflections (some inverted faces when rendering multiple layers onto the same cubemap).  (seems like the X-faces of the cubemap are either rotated/inverted, or rendering onto the wrong face; only occurs when both scaled space and local scenery are being rendered)

OpenGL Core doesn't have those problems.... (have not tested legacy openGL)

So yes, seems like forcing openGL Core is likely to be the answer for future releases of TU (and SSTU).  Not sure why the regressions, and at this point I'm not sure if they are in Unity (engine), KSP, or something in my code that wasn't setup properly/fully (but still happened to work).

 

I did 'fix' the DX11 part-icon issues though.... simply by applying my existing icon shader to the parts icon-models.  Note the couple of new parts that still have icon-shader issues, as they are unpatched and still using the (problematic) stock icon shaders.  Likely not needed in any openGL variant.

 

More progress... I think that TU is just about ready for initial 1.4.1 public (testing) release, after a bit more testing.  Likely tomorrow / Saturday.  (at which point I can start working on the SSTU updating)

[tater]

I'm happy to do what I can to check TU on the mac for ya.

[Pappystein]

On 3/15/2018 at 7:15 PM, Jimbodiah said:

They actually added wolfy's gemini capsule to KSP I think

Um,  no, not really.  It is a 0.625 to 1.875m conical piece that has Gemini sugar-scoops and 2 doors (in a texture.)   It appears to follow the conical angles of the basic Mk1-3 pod in game already so it makes me wonder is this a new part or a masivly rebuilt existing Mk1-3.

The texturing is cool but it is short and fat compared to a Gemini.   Either FASA's Gemini or BDB/TRAILS/Gusmobile's Gemini are better proportioned.   FASA has much more realistic texture and shape.   BDB/TRAILS/GusMobile has that "Kerbal Kuality" that is awesome in it's own right.

 

 

 

 

 

[Starwaster]

On 3/15/2018 at 7:32 PM, Shadowmage said:

Strangely (but not surprisingly), this is what I am seeing as well.  1.4.1 - DX9/DX11 have new issues that didn't exist in 1.3.1 regarding reflections (some inverted faces when rendering multiple layers onto the same cubemap).  (seems like the X-faces of the cubemap are either rotated/inverted, or rendering onto the wrong face; only occurs when both scaled space and local scenery are being rendered)

OpenGL Core doesn't have those problems.... (have not tested legacy openGL)

So yes, seems like forcing openGL Core is likely to be the answer for future releases of TU (and SSTU).  Not sure why the regressions, and at this point I'm not sure if they are in Unity (engine), KSP, or something in my code that wasn't setup properly/fully (but still happened to work).

Skybox flipping (even on just two faces) is not unknown. Unity problem (I think, as it's been brought up before) not KSP. As to why just DX11 I don't know...

Edit: A thought, perhaps it's something similar to the attach node issue that we had in KSP where attach node facing was mandated but never enforced and then when they did start enforcing it parts stopped attaching until their nodes were fixed.

It's possible that Unity has been applying corrections on skymap renderings and now that code has been deprecated...

Edited March 17, 2018 by Starwaster

[tater]

https://www.ulalaunch.com/docs/default-source/exploration/dual-thrust-axis-lander-(dtal)-2009.pdf

Horizontal lander stuff. Just leaving it here.

[Kaa253]

3 hours ago, tater said:

https://www.ulalaunch.com/docs/default-source/exploration/dual-thrust-axis-lander-(dtal)-2009.pdf

Horizontal lander stuff. Just leaving it here.

Awesome NASA stuff - thanks for providing the great read!
Naturally, now I want to make and try it

[Shadowmage]

20 hours ago, Starwaster said:

Skybox flipping (even on just two faces) is not unknown. Unity problem (I think, as it's been brought up before) not KSP. As to why just DX11 I don't know...

Edit: A thought, perhaps it's something similar to the attach node issue that we had in KSP where attach node facing was mandated but never enforced and then when they did start enforcing it parts stopped attaching until their nodes were fixed.

It's possible that Unity has been applying corrections on skymap renderings and now that code has been deprecated...

For me it is confusing as I'm using the Unity built-in features for cubemap rendering.  More confusing that it worked fine in KSP 1.3.1.  And even more confusing that it works fine with OpenGL core.

reflectionCamera.RenderToCubemap(envMap, faceMask);

Entirely Unity API's functions there; calling the 'RenderToCubemap' method on a camera, providing it with the cubemap to render onto (envMap), and which cube face(s) to render (faceMask).

 

Don't think I'm going to spend to much time on it though.  Simply going to state that using 'force-glcore' will be mandatory for SSTU / TU use.  Works fine for me.

[Theysen]

Does glcore overwrite AA like OpenGL does and needs manual overwrite in NVIDIA settings? 

Had not have a chance to try it out. 

[COL.R.Neville]

trying to use the -glcore switch but not working out. 

throwing lots of shader tool exceptions. everything shows up,  the icps' have textures on them but all of the other parts do not. either in the part list or in the vab actual. and once you try to load a part it freezes the vab. 

heres the last part before it froze the vab.  it can never just work with these version changes hehe. does give you a chance to try out new things though. 

Spoiler

[EXC 21:09:34.708] TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
    KSPShaderTools.SSTURecolorGUI+<updateButtonVisibility2>d__14.MoveNext ()
    UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
[LOG 21:09:38.034] SSTU-SC-C-CM added to ship - part count: 2
[EXC 21:09:38.137] TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
    KSPShaderTools.SSTURecolorGUI+<updateButtonVisibility2>d__14.MoveNext ()
    UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
[EXC 21:09:40.358] TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
    KSPShaderTools.SSTURecolorGUI+<updateButtonVisibility2>d__14.MoveNext ()
    UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
[LOG 21:09:42.089] deleting part SSTU-SC-C-CMX and all children
[LOG 21:09:42.325] ScaleModList: listSize 451 maxListSize 1403
[ERR 21:12:30.134] [Upgrades]: Module SSTUInterstageFairing threw during OnLoad in editor: System.TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
  at SSTUTools.SSTUInterstageFairing.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 
  at PartModule.ApplyUpgradeNode (System.Collections.Generic.List`1 appliedUps, .ConfigNode node, Boolean doLoad) [0x00000] in <filename unknown>:0 

[ERR 21:12:37.751] Module SSTUNodeFairing threw during OnStart: System.TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
  at SSTUTools.SSTUNodeFairing.initialize () [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUNodeFairing.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 

[ERR 21:12:37.753] Module SSTUNodeFairing threw during OnStart: System.TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
  at SSTUTools.SSTUNodeFairing.initialize () [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUNodeFairing.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 
 

 

[mechanicH]

On 3/17/2018 at 1:51 PM, tater said:

https://www.ulalaunch.com/docs/default-source/exploration/dual-thrust-axis-lander-(dtal)-2009.pdf

Horizontal lander stuff. Just leaving it here.

JPL’s ATHLETE (Figure 17) can be folded for flight and stowed in whatever orientation is most convenient for packaging with other LSS elements.

This is actually doable with @RoverDude stuff....the legs look exactly the same.   Very cool article.

[Starwaster]

On 3/18/2018 at 12:46 PM, Shadowmage said:

Don't think I'm going to spend to much time on it though.  Simply going to state that using 'force-glcore' will be mandatory for SSTU / TU use.  Works fine for me.

Up to you, but you could just swap the two faces if DX11 is in use.

[Shadowmage]

3 minutes ago, Starwaster said:

Up to you, but you could just swap the two faces if DX11 is in use.

Except I'm using the built-in cubemap rendering routines -- I cannot swap faces.  The Unity provided method positions/rotates the camera for the input face(s) provided, and renders it onto the input texture -- I have no control over camera orientation for any given face, nor can I change where in the cubemap any given face is rendered, or in what orientation.

Thinking on it more -- likely that there is nothing that I can do in order to fix the problem.  Still going to do a bit more investigation when I can, as I would at least like to know what the problem is; at the very least I'd like to file a bug report with Unity on the problem.

 

15 hours ago, COL.R.Neville said:

trying to use the -glcore switch but not working out. 

throwing lots of shader tool exceptions. everything shows up,  the icps' have textures on them but all of the other parts do not. either in the part list or in the vab actual. and once you try to load a part it freezes the vab. 

heres the last part before it froze the vab.  it can never just work with these version changes hehe. does give you a chance to try out new things though. 

  Reveal hidden contents

[EXC 21:09:34.708] TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
    KSPShaderTools.SSTURecolorGUI+<updateButtonVisibility2>d__14.MoveNext ()
    UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
[LOG 21:09:38.034] SSTU-SC-C-CM added to ship - part count: 2
[EXC 21:09:38.137] TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
    KSPShaderTools.SSTURecolorGUI+<updateButtonVisibility2>d__14.MoveNext ()
    UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
[EXC 21:09:40.358] TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
    KSPShaderTools.SSTURecolorGUI+<updateButtonVisibility2>d__14.MoveNext ()
    UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
[LOG 21:09:42.089] deleting part SSTU-SC-C-CMX and all children
[LOG 21:09:42.325] ScaleModList: listSize 451 maxListSize 1403
[ERR 21:12:30.134] [Upgrades]: Module SSTUInterstageFairing threw during OnLoad in editor: System.TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
  at SSTUTools.SSTUInterstageFairing.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 
  at PartModule.ApplyUpgradeNode (System.Collections.Generic.List`1 appliedUps, .ConfigNode node, Boolean doLoad) [0x00000] in <filename unknown>:0 

[ERR 21:12:37.751] Module SSTUNodeFairing threw during OnStart: System.TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
  at SSTUTools.SSTUNodeFairing.initialize () [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUNodeFairing.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 

[ERR 21:12:37.753] Module SSTUNodeFairing threw during OnStart: System.TypeLoadException: Could not load type 'KSPShaderTools.KSPShaderLoader' from assembly 'SSTUTools'.
  at SSTUTools.SSTUNodeFairing.initialize () [0x00000] in <filename unknown>:0 
  at SSTUTools.SSTUNodeFairing.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 
 

 

You are using incorrect versions somewhere;  SSTU is not updated for KSP 1.4.1 yet, and the newer TU is ONLY usable in KSP 1.4.1.

So... figure out what version of KSP you are using first, and then we can tell you what mod version(s) to use.  If you actually want to use SSTU, then you need KSP 1.3.1.

[Shadowmage]

Apparently the official stance from SQUAD is that DX11/DX12 are entirely unsupported. 

20 hours ago, JPLRepo said:

The simple answer is KSP does not support anything except dx9 at this point in time; even though Unity might; forcing Unity to use dx11/12 etc will produce unexpected and incorrect displays in KSP.

 

Considering this statement, and the fact that OpenGL-Core does work on all platforms that KSP runs on...  yeah, seems entirely likely that I'll be dropping DX9/11/12 support from TU (and SSTU) entirely.  Still want to do some further investigation to see if I can find the cause of the strange cubemap rendering... but I also don't want to spend too much time on trying to fix something that is not going to receive any support in the base game.

[Electrocutor]

51 minutes ago, Shadowmage said:

Apparently the official stance from SQUAD is that DX11/DX12 are entirely unsupported. 

 

Considering this statement, and the fact that OpenGL-Core does work on all platforms that KSP runs on...  yeah, seems entirely likely that I'll be dropping DX9/11/12 support from TU (and SSTU) entirely.  Still want to do some further investigation to see if I can find the cause of the strange cubemap rendering... but I also don't want to spend too much time on trying to fix something that is not going to receive any support in the base game.

Unfortunately, in that thread, someone had also shown there are bugs in OpenGL.

[ Update ]
The issue of the top row of icons being cut off and the bottom row overlapping the UI is not related to renderer; it is present in all modes.

Edited March 19, 2018 by Electrocutor

[Shadowmage]

42 minutes ago, Electrocutor said:

Unfortunately, in that thread, someone had also shown there are bugs in OpenGL.

Indeed, but they have to support OpenGL officially, as that is the only option on Linux/Mac (two of their officially supported platforms).  Contrast to DX11/12, where they don't officially have to support it, and have in fact explicitly stated that it is intentionally not supported.

Not that I'm happy with those answers, even in the slightest, but that is the current state of things that I have to work with.

 

44 minutes ago, Electrocutor said:

I can confirm that in any mode except dx9, there is some kind of invisible something at the top of the screen that interferes with rendering sometimes. I'll try to figure out more specifics.

If you are referring to the editor-part-list-icons being cropped/offset under OpenGL -- that should be a relatively simple thing to fix on their end.  The precise problem is the inverted Y coordinates that are fed into the shader -- someone simply needs to adjust the shaders for API specific Y-coordinate handling for the clip test.  Something similar to:  https://github.com/shadowmage45/TexturesUnlimited/blob/master/CustomShaders/SSTU-MaskedIcon.shader#L66-L68 ... but with the proper APIs listed.

(This is actually a problem that I had to solve when I was trying to figure out the implementation of icon-shaders, hence why I know exactly what the problem and solution are... its already been 'solved';  however even my code might need some adjustments with this Unity version update)

[COL.R.Neville]

was using 1.41 ksp with the 1.41 version of TU and the latest version of sstu.  

[Shadowmage]

Just now, COL.R.Neville said:

was using 1.41 ksp with the 1.41 version of TU and the latest version of sstu.  

There is your problem -- SSTU does not work with KSP 1.4.1.  That is why the title and OP states '[WIP][1.3.1]'

If you want to use SSTU, you need to revert to using KSP 1.3.1.  Or wait until it is ready and an update is published.

[Electrocutor]

Just now, Shadowmage said:

There is your problem -- SSTU does not work with KSP 1.4.1.  That is why the title and OP states '[WIP][1.3.1]'

If you want to use SSTU, you need to revert to using KSP 1.3.1.  Or wait until it is ready and an update is published.

Are you planning to revamp sstu to utilize the stock texture/model switching?