SSTU - Shadow Space Technologies Unlimited

SSTU - Shadow Space Technologies Unlimited

98.5k Downloads

VAB icon issue in the latest 1.3 dev update

taterkerman opened this issue · 23 comments

commented

screen shot 2017-05-27 at 11 32 15 pm

commented

Hmm... interesting. The icons all seemed to look okay to me (I did check at least the fuel tanks for basic functionality). Were there any exceptions in the log during loading, and were there any other icon/rendering related errors visible?

commented

I'll reopen KSP and check the log for you.

Note that that is career mode, it's fine in sandbox.

commented

LOG 08:30:48.805] ------------------- initializing editor mode... ------------------
[LOG 08:30:48.805] editor started
[LOG 08:30:48.812] Loading Depletion Nodes
[LOG 08:30:48.812] DepNodeCount: 0
[LOG 08:30:48.812] Loading Biome Nodes
[LOG 08:30:48.812] BiomeNodeCount: 0
[LOG 08:30:48.812] Loading Planet Nodes
[LOG 08:30:48.812] PlanetNodeCount: 0
[LOG 08:30:48.821] [ScenarioDestructibles]: Loading... 0 objects registered
[LOG 08:30:48.821] [ScenarioUpgradeableFacilities]: Loading... 0 objects registered
[LOG 08:30:48.930] Untitled Space Craft loaded!
[WRN 08:30:48.984] HighlightingSystem : Framebuffer depth data is not available and can't be used to occlude highlighting. Highlighting occluders enabled.
[WRN 08:30:49.269] The referenced script on this Behaviour (Game Object '') is missing!
[WRN 08:30:49.269] The referenced script on this Behaviour (Game Object '') is missing!
[WRN 08:30:49.269] The referenced script on this Behaviour (Game Object '') is missing!
[LOG 08:30:49.336] [UIMasterController]: ShowUI

The part in the right click looks normal, and placing the part looks normal. The part is unlocked, and paid for in R&D.

commented
commented

Yeah, I'm not seeing anything in the full log either. A bit strange.

The problem has persisted across game reloads? And is in career only? Does the part work fine when pulled out from the parts list?

The career only bit would point to it being a problem with the upgrade functionality, though I couldn't say what off the top of my head. At least that gives me a place to start investigating.

commented

I reloaded a couple times and it persisted. It is only career. It looks fine in sandbox even with part upgrades turned off (I made sure to turn them off in the SSTU diff tab).

I will experiment right now.

commented

It goes away with he first upgrade to the SSTU tank (Advanced Rocketry).

commented

That could explain it, as when you do some part upgrades to get the upgraded SSTU tank it is not on the top row any longer. The parts in the actual editor look fine.

commented

What is more confusing is that what you are seeing is a problem that I already 'fixed' (inverted screen coordinates in the shader). The icons did exactly that for me in the top row prior to the fix. Were fine on any other row, but clipped a bit on the top (and also overlapped/went out of bounds on the bottom row(s)).

Is entirely possible that this is a directX vs. OpenGL difference (as you are still on a Mac, correct? which uses OpenGL as far as I know).

So this might be a case of me needing to figure out compiler directives for shader use (e.g. #IFDEF), to compile two separate shaders from the same source, depending on the path being used (openGL vs directX).

I'll do some testing on this tonight on my install and see if it occurs in DirectX mode, and then swap over to OpenGL to see what goes on there.

commented

Yeah, seems like that might be the deal -- OpenGL vs. DirectX handling of UV/screen-space coordinates

From: https://docs.unity3d.com/Manual/SL-PlatformDifferences.html

Clip space coordinates

Similar to Texture coordinates, the clip space coordinates (also known as post-projection space coordinates) differ between Direct3D-like and OpenGL-like platforms:

    Direct3D-like: The clip space depth goes from 0.0 at the near plane to +1.0 at the far plane. This applies to Direct3D, Metal and consoles.

    OpenGL-like: The clip space depth goes from –1.0 at the near plane to +1.0 at the far plane. This applies to OpenGL and OpenGL ES.

Inside Shader code, you can use the UNITY_NEAR_CLIP_VALUE built-in macro to get the near plane value based on the platform.

Inside script code, use GL.GetGPUProjectionMatrix to convert from Unity’s coordinate system (which follows OpenGL-like conventions) to Direct3D-like coordinates if that is what the platform expects.

More Info:
https://docs.unity3d.com/401/Documentation/Components/SL-BuiltinMacros.html

commented

Yes, on a Mac.

commented

The fact that it is different in sandbox with upgrades not applied is... strange. I'm looking at the code and there doesn't appear to be any sort of validation going on that would cause it.

Seems likely I'll have to put some additional debugging in place to figure out where/what is going on with the icon.

Does the part itself look fine when pulled into the editor -- is it only the icon that is messed up? (Icons are created during the initial loading sequence during part compilation, prior to any game/upgrade stuff being loaded/present).

commented

Huh... looking at the icon a bit further.... this might actually just be a problem with my icon-shader. It uses some shader functions in order to discard pixels that are outside of specific bounds, and it looks like I might have those bounds setup a bit.... incorrectly.

The top dome model uses the stock icon shader, which is why it renders correctly. But if you look at the model for the fuel tank itself, it appears to be clipped/trimmed horizontally, rather than merely mispositioned.

If you scroll/move the tank in the editor parts list, does the problem go away? -- Is it only a problem when the tank is in the top row of the parts list?

(thought I had the clipping area fixed up properly, but I might have missed something..... trying to work out the internals of the stock icon shader without access to the source is... well... a bunch of guesswork).

commented

Minor issue, but in the current (?) 1.3 version (DLed Sunday) there is an icon issue. Go to VAB. Scroll icons for any of the parts that are numerous enough to need scrolling. The icons will overlap the Funds, CM, etc on the bottom. Check by going to the Aerodynamics section that is filled with NON SSTU parts, and that works normally.

commented

Yep, this is all part of the exact same issue.

The precise problem is that the screen-space clipping Y-coordinates are inverted on OpenGL; thus it is clipping at the top where it should clip at the bottom, relatively.

commented

Same issue in VAB. Started new career, gave myself science, unlocked Basic Rocketry, went to VAB---looks like my original image. As soon as it's off the top row, looks as it should.

commented

Hmm... well thanks for giving it a try :)

I'll see about duplicating the issue on this end with -forceopengl or whatever the command switch is, so that I can at least test any further 'solutions' myself. Will let you know what I come up with.

commented

@taterkerman can you give the following shader file a try and see if it fixes your VAB icon problems?

sstushaders-osx.zip

Locate the existing shader file at GameData/SSTU/Shaders/sstushaders-osx.ssf and replace it with the file inside the zip from the link above. If successful, your icons should have no more problems.

commented

Yeah, I'm tasked with making some green chile cheeseburgers, but after dinner I'll try it out for you.

commented

Finally made a bit of progress on this today, might have an updated shader pack for you to test a bit later tonight.

commented

@taterkerman could you give this updated shader pack a test to see if it fixes your icon-clipping issues in the editor? (fixed in windows-opengl now, -should- be fixed in linux/osx as well, but I cannot test those)

sstushaders-osx.zip

Please let me know if it does/doesn't work properly, and I can either mark it as fixed, or investigate further...

commented

Apparently while it is now fixed on OpenGL... it is no longer fixed for DirectX. As it is now compiling for both, I likely need to use something other than compile directives (I have a feeling they are both set to true at compile time).

Will need to do (in editor?) shader-debugging to see if one of a few supposed 'tests' actually work properly to detect dx vs ogl coordinate inputs.

Another semi painful alternative would be to do run-time detection of the rendering api, and compile separate packages for win-dx and win-gl (osx and linux always use openGL, so no changes there).

commented

Pretty sure I have this one -actually- fixed now.

At least it works properly on Windows DX9 and OpenGL (with autodetection of what subroutines to use).