[1.9.x] Textures Unlimited - PBR-Shader, Texture Set, and Model Loading API

[Electrocutor]

Actually, if you look at my code, what you are saying is that the Skybox is rendering on top of the scene view: that was the whole purpose of having a skybox that has only the atmosphere in it.

[Shadowmage]

3 minutes ago, Electrocutor said:

Actually, if you look at my code, what you are saying is that the Skybox is rendering on top of the scene view: that was the whole purpose of having a skybox that has only the atmosphere in it.

Did you try using the TU/Skybox shader that I sent?  There may well be some issues with that cube-copy shader. 

Was why I posted a link to the 'working' example I put together.  The concept works (at least in my code).... so now you get the fun of figuring out what we did differently, and why the one works and not the other

The setup bits in my code are:

            RenderSettings.defaultReflectionMode = UnityEngine.Rendering.DefaultReflectionMode.Skybox;
            if (cameraObject == null)
            {
                cameraObject = new GameObject("TRReflectionCamera");
                reflectionCamera = cameraObject.AddComponent<Camera>();
                reflectionCamera.enabled = false;
                reflectionCamera.clearFlags = CameraClearFlags.SolidColor;
                reflectionCamera.nearClipPlane = 0.01f;
                reflectionCamera.farClipPlane = 3.0e7f;
                reflectionCamera.cullingMask = 0;
                MonoBehaviour.print("TUREFMAN2 - created camera");
            }
            if (skyboxTexture == null)
            {
                RenderTexture skyboxTexture = new RenderTexture(envMapSize, envMapSize, 24);
                skyboxTexture.dimension = UnityEngine.Rendering.TextureDimension.Cube;
                skyboxTexture.format = RenderTextureFormat.ARGB32;
                skyboxTexture.wrapMode = TextureWrapMode.Clamp;
                skyboxTexture.filterMode = FilterMode.Trilinear;
                skyboxTexture.autoGenerateMips = false;
                skyboxTexture = createTexture(envMapSize);
                MonoBehaviour.print("TUREFMAN2 - created skybox texture");
            }
            if (skyboxShader == null)
            {
                skyboxShader = KSPShaderTools.TexturesUnlimitedLoader.getShader("TU/Skybox");
                if (skyboxShader == null)
                {
                    MonoBehaviour.print("ERROR: SSTUReflectionManager - Could not find skybox shader.");
                }
                skyboxMaterial = new Material(skyboxShader);
                skyboxMaterial.SetTexture("_Tex", skyboxTexture);
                MonoBehaviour.print("TUREFMAN2 - created skybox material and assigned tex");
            }
            if (probe == null)
            {
                probe = this.gameObject.AddComponent<ReflectionProbe>();
                probe.mode = UnityEngine.Rendering.ReflectionProbeMode.Realtime;
                probe.refreshMode = UnityEngine.Rendering.ReflectionProbeRefreshMode.EveryFrame;
                probe.clearFlags = UnityEngine.Rendering.ReflectionProbeClearFlags.Skybox;
                probe.timeSlicingMode = UnityEngine.Rendering.ReflectionProbeTimeSlicingMode.AllFacesAtOnce;
                probe.hdr = false;
                probe.size = new Vector3(2000, 2000, 2000);
                probe.resolution = envMapSize;
                probe.enabled = true;
                probe.cullingMask = 0;
                MonoBehaviour.print("TUREFMAN2 - created refl. probe");
            }

The functional 'update' bits of my code are all in one little block (using a GUI to control the 'renderXXX-YYY' boolean values; allowing run-time changing of configuration):

                int camMask = 0;
                if (renderGalaxySky) { camMask = camMask | galaxyMask; }
                if (renderAtmoSky) { camMask = camMask | atmosphereMask; }
                if (renderScaledSky) { camMask = camMask | scaledSpaceMask; }
                if (renderScenerySky) { camMask = camMask | sceneryMask; }
                reflectionCamera.cullingMask = camMask;
                reflectionCamera.enabled = true;
                reflectionCamera.gameObject.transform.position = FlightIntegrator.ActiveVesselFI.Vessel.transform.position;
                reflectionCamera.RenderToCubemap(skyboxTexture);
                reflectionCamera.enabled = false;
                skyboxMaterial.SetTexture("_Tex", skyboxTexture);
                RenderSettings.skybox = skyboxMaterial;
                
                probe.gameObject.transform.position = FlightIntegrator.ActiveVesselFI.Vessel.transform.position;
                camMask = 0;
                if (renderGalaxyProbe) { camMask = camMask | galaxyMask; }
                if (renderAtmoProbe) { camMask = camMask | atmosphereMask; }
                if (renderScaledProbe) { camMask = camMask | scaledSpaceMask; }
                if (renderSceneryProbe) { camMask = camMask | sceneryMask; }
                probe.cullingMask = camMask;

                probe.enabled = reflectionsEnabled;

 

One of the main differences I'm seeing between our setups is that I'm using RenderTexture set to be a cubemap, and you are using a standard CubeMap.  Most of the rest seems to be functionally equivalent.  The one other bit that I'm doing is setting 'RenderSettings.defaultReflectionMode' during my setup pass... no clue what it is set to by default....

Likely more differences between the codebases if you were to really dig into it.... certainly it is one of these differences that is allowing one to work, but not the other.

[Shadowmage]

@Electrocutor

At the very least, out of all of this experimentation over the last few days, I now have a 'fixed' skybox shader that might let me optimize the TU reflection system a bit more.  Wonder how many other issues I was running into during initial development of TU that were caused by the incorrect culling on that shader?

I'll likely be doing a bit more experimentation with it to see exactly how far down I can trim the reflection system, as well as doing some performance testing between the existing and the 'new' setups.

[Electrocutor]

1 hour ago, Shadowmage said:

@Electrocutor

At the very least, out of all of this experimentation over the last few days, I now have a 'fixed' skybox shader that might let me optimize the TU reflection system a bit more.  Wonder how many other issues I was running into during initial development of TU that were caused by the incorrect culling on that shader?

I'll likely be doing a bit more experimentation with it to see exactly how far down I can trim the reflection system, as well as doing some performance testing between the existing and the 'new' setups.

Sounds fun. If you're interested, I can explain what I am thinking for the layer0 reflections.

My thought is that each vessel only needs one environment probe at the center of the overall vessel bounding box with half the renders semi-static, and the other real-time; and they can be disabled when outside render-range. In the case of multiple vessels (including EVA Kerbal) within a vicinity, you need to create one real-time probe on layer0 on each vessel when they near-enough to each other so they can see each other and you need to move it within the bounding boxes of the vessel to be closest to the approaching other vessel. This way, if a Kerbal were to climb a ladder and stand in front of a large glass window, he could see himself. This layer0 camera would only need 1 direction render because it would always be facing the opposing vessel.

The nastiness with this setup is the code to follow the colliders of the vessel to find the nearest place to position the camera. You'd also need to use importance, intensity, and other tricks to make sure that the blending or overlay of the layer0 only showed up on meshes nearest to the camera.

Edited October 23, 2018 by Electrocutor

[Shadowmage]

16 minutes ago, Electrocutor said:

This way, if a Kerbal were to climb a ladder and stand in front of a large glass window, he could see himself. This layer0 camera would only need 1 direction render because it would always be facing the opposing vessel.

The problems I ran into when investigating this originally, is that during the captures for the reflections for each of those 'per-vessel' probes, you need to somehow set the culling up so that it doesn't capture meshes from the vessel it is parented to (assuming the probe is somewhere 'inside' the vessel).

TR/TRR did this with 'per part' render-textures, temporarily flipping the layer of each part as that parts reflection was rendered; otherwise as the camera is 'inside' of a part, you get strange artifacts of backface culling/some front faces showing through.

Would love to give this some further thought though, as soon as the current update mess is complete.  Adding vessel (and esp. kerbal/EVA) reflections has been on my TODO list since the beginning.

[Electrocutor]

I'd have to implement it to verify, but from random testing, so long as your camera is on the collider line and nearclip is positive, you won't pick up the stuff you are looking through.

If you wanted to go the easy route first, you could just use a special syntax for designating window meshes, then place a layer0 one-direction camera on each of them. The problem here is that some vessels get very big with lots and lots of windows, which would turn your potato into a baked potato.

[Shadowmage]

1 minute ago, Electrocutor said:

I'd have to implement it to verify, but from random testing, so long as your camera is on the collider line and nearclip is positive, you won't pick up the stuff you are looking through.

Interesting, and yes, should work (using near-clip).  I think there is a 'vesselBounds' somewhere in the vessel struct that you could use to dynamically determine this value.  Of course, that would still clip anything that came inside that distance -- e.g. a kerbal clambering on a ladder that was not on an extremity of the vessel would not show up in the reflection.

Its a good starting point though   (probably not the only bit of magic that will be needed, but likely to be one of them)

[Electrocutor]

2 minutes ago, Shadowmage said:

Interesting, and yes, should work (using near-clip).  I think there is a 'vesselBounds' somewhere in the vessel struct that you could use to dynamically determine this value.  Of course, that would still clip anything that came inside that distance -- e.g. a kerbal clambering on a ladder that was not on an extremity of the vessel would not show up in the reflection.

Its a good starting point though   (probably not the only bit of magic that will be needed, but likely to be one of them)

I can guarantee that for this you will have to settle for "good enough", because there are just way to many edge cases.

Unrelated: Since you were talking about other shaders, you may consider adding lighting from planets i.e. planet reflective/indirect light. I could be wrong, but I think the ambientSkyColor is set for all SOI. This would greatly enhance TU while in orbit.

[Shadowmage]

@Electrocutor

Interesting thought on fixing the layering issues for probe capture/etc...  might be possible to fix through setting the material.renderQueue of the materials/etc that stock is using for their atmo and galaxy boxes, so that they simply render in the proper order to begin with... (behind the world).  Investigating now, will let you know what I find.

 

[Shadowmage]

9 hours ago, Shadowmage said:

might be possible to fix through setting the material.renderQueue of the materials/etc that stock is using for their atmo and galaxy boxes,

Didn't work as far as I could see -- perhaps I'm adjusting the wrong renderers/transforms.  Going to keep investigating this a bit, as according to the Unity docs, it -should- be working.  Might have to do a game-hierarchy dump and figure out where exactly the atmosphere game objects reside...

Nor was I able to get multi-pass rendering working properly for anything but 'one face at a time'.  It looks like the Unity Camera keeps an internal renderTexture that it captures to, and then blits that into the cubemap; when I only clear depth buffer for secondary passes over the cubemap, this internal texture is never cleared, and so accumulates all frame data during the render and writes it into every face into the cubemap.... hmm... maybe one camera per layer?

However I think I did finally find the Unity Convolution shaders....so might be able to move TU away from using reflection probes entirely if I can figure out how to use them.

[Gordon Dry]

Just did a test with KSP 1.5.1 and the latest dev and the TURD configs - still several parts are transparent like before.
Actually I only see this issue on some specific BDB parts like that Atlas part and engine mounts or complete engines, like:

And for BDB there is no custom config. (TURD or BDB itself - nothing about BDB in there)

[Shadowmage]

General development update -- cleanup and polish on the 1.5 versions is coming along nicely.  I think the features and shaders have mostly stabilized, so now it is just down to documentation and more testing/bug-fixing.  Barring any major issues, I will be packing up a release on Saturday.

Along with this release I have added/will be adding much more documentation to the wiki, covering everything from shader setup and use, texture-set config creation, clear down to creation of metallic and mask textures for use in the recoloring system.  I will be providing a set of example patches in the repository that mod-makers or end-users can use for template purposes, but also as functional examples of how things are intended to work -- these will be a set of patches (and maybe 1-2 mask assets) that would be fully functional and actually effect stuff if added to the game, but will be distributed only by download from the wiki/repo (I will still not be shipping with any part/texture/etc altering configs).

[Shadowmage]

17 hours ago, Gordon Dry said:

Just did a test with KSP 1.5.1 and the latest dev and the TURD configs - still several parts are transparent like before.
Actually I only see this issue on some specific BDB parts like that Atlas part and engine mounts or complete engines, like:
 

And for BDB there is no custom config. (TURD or BDB itself - nothing about BDB in there)

Strange, and interesting, but really doesn't mean much at this point.

1.) TURD has not been updated to support the newer TU, there may be incompatibilities there.
2.) TU does not touch parts unless instructed by config.  So I cannot see how what you are saying is true 'And for BDB there is no custom config' -- if there really are no configs for those parts, then they won't have been adjusted by TU.

If you wanted to turn this into a proper 'bug report' -- install just TU and BDB (zero configs/patches), and let me know if the issue persists.  This will eliminate any potential 'wrong' configs from being the culprit (I do not offer support for third-party configs, except to the author of those configs).  If the issue persists with only TU and BDB installed (zero configs/patches), it would point to some other low-level KSP-centric incompatibility (which would be a bug that I should/could solve).

[Gordon Dry]

Okay, I do a test with this GameData and no additional configs of any kind:

000_TexturesUnlimited\
B9PartSwitch\
BlendshapeModelLoader\
Bluedog_DB\
Bluedog_DB_Extras\
CommunityResourcePack\
DMagicScienceAnimate\
Squad\
ModuleManager.3.1.0.dll

1. -force-glcore
2. -force-d3d11

Results:

1. already issue (-force-glcore)

Spoiler

2. also issue, but different, somehow "inverted" (-force-d3d11):

Spoiler

 

Edited October 25, 2018 by Gordon Dry

[Shadowmage]

12 minutes ago, Gordon Dry said:

Okay, I do a test with this GameData and no additional configs of any kind:

000_TexturesUnlimited\
B9PartSwitch\
BlendshapeModelLoader\
Bluedog_DB\
Bluedog_DB_Extras\
CommunityResourcePack\
DMagicScienceAnimate\
Squad\
ModuleManager.3.1.0.dll

1. -force-glcore
2. -force-d3d11

Results:

1. already issue (-force-glcore)

 

Thanks for doing the testing, much appreciated.  Are you seeing any problems on stock parts, or is it only mod-added parts that are having issues?  (I really don't feel like downloading random mods to test stuff, so a stock test-case is always best if possible)

[Gordon Dry]

^ Updated

[Shadowmage]

15 minutes ago, Gordon Dry said:

2. also issue, but different, somehow "inverted" (-force-d3d11):

Interesting -- thanks for trying both graphics APIs.  Almost looks like the icon-shaders are being used on those parts (with the screen-space clip code causing things to disappear).

[Gordon Dry]

Actually I see this issue on the following parts: (with -force-d3d11)

BDB:
Bossart-BT7-700 Balloon Fuel Tank
Centaur-D 2160 Fuel Tank
Centaur-D 2660 Fuel Tank
Castor-4 Castor-2 Solid Rocket Motor
Castor-MGU27A Algol Solid Rocket Booster
Delta-GEM-40I "Garnet" Solid Rocket Booster
Delta-GEM-60XL "Lapis" Solid Rocket Booster
GEM-40 Solid Rocket Booster
GEM-46 Solid Rocket Booster
GEM-60 Solid Rocket Booster
LR-87-11-1 Liquid Fuel Engine
LR-87-11A Liquid Fuel Engine
LR-87-3 Liquid Fuel Engine
LR-87-7 Liquid Fuel Engine
LR-87-LH2 Cryogenic Engine
LR-87-LH2-V Cryogenic Engine
Star-10-LYC Alcyone Solid Rocket Motor
Star-20-IIA "Aquilae" Solid Rocket Motor
Star-37FNV "Beran" Solid Rocket Motor
Titan IV "Selene" Solid Rocket Booster Upgrade
BSA-0150-0120 - MOL Large Structural Adapter
(FASA Launch Tower) works but weird part icon
(FASA Umbilical Tower) works but weird part icon
(Delta-K-2-70 Fairing Adapter Tank) works but NO part icon

stock:
(TT18-A Launch Stability Enhancer) works but weird part icon
(AE-FF1 Airstream Protective Shell (1.25m)) works but weird part icon

I stop here...
So there may be more.

@CobaltWolf

[CobaltWolf]

3 minutes ago, Gordon Dry said:

Actually I see this issue on the following parts: (with -force-d3d11)

@CobaltWolf

@Shadowmage I don't know what the issue would be. Most of the parts listed have B9 Part Switch on them, is there any known issue between B9 and TU?

[Shadowmage]

15 minutes ago, CobaltWolf said:

is there any known issue between B9 and TU?

Not that I'm currently aware of.... but I also don't use B9 (or any other texture-switch mods in my games), so would have no reason or opportunity to be aware of anything.

@Gordon Dry

Apparently I'll have to d/l BDB & B9 this evening/weekend to do some testing, seems to be no other way around it (no guarantees though, I really hate downloading and installing random mods just for testing....).  Will let you know what I find out.

Edit:  The stuff regarding part icons is merely because Stock KSP has not compiled their shaders with DX11 and OpenGL enabled.  Normally -all- part icons are screwed up when using those gfx APIs, but TU does its best to fix the icons that it can.  The remaining parts that need to be fixed -- well.. I just need someone to tell me what shaders those parts use, and it'll be a simple affair to add those to the patch list (I normally don't have stock parts enabled in my games, so I probably don't even know there are issues with some of them).

Edited October 25, 2018 by Shadowmage

[Gordon Dry]

I just recognized the following:

1. KSP stock still did not fix the issue of hazy-blue part icons in VAB when using -force-d3d11
2. when using latest TU dev this issue is somehow fixed, the part icons in VAB are mostly rendered correctly

Wirhout TU - but -force-d3d11:

[Shadowmage]

2 minutes ago, Gordon Dry said:

I just recognized the following:

1. KSP stock still did not fix the issue of hazy-blue part icons in VAB when using -force-d3d11
2. when using latest TU dev this issue is somehow fixed, the part icons in VAB are mostly rendered correctly

Wirhout TU - but -force-d3d11:

 

Yep -- that is a stock problem that TU mostly fixes.  See my edited post above   (can probably fix the rest, but need to know what shader the 'broken' parts are using)

[Electrocutor]

Icons Missing in dx11:

The external command seat uses KSP/Alpha/Cutoff

The fairings use KSP/Diffuse and KSP/Bumped Specular (Cutoff)

The mk1 parachute uses KSP/Alpha/Cutoff Bumped

[Shadowmage]

3 minutes ago, Electrocutor said:

Icons Missing in dx11:

The external command seat uses KSP/Alpha/Cutoff

The fairings use KSP/Diffuse and KSP/Bumped Specular (Cutoff) 

The mk1 parachute uses KSP/Alpha/Cutoff Bumped 

Thanks, have added those three to the list of 'stock icon shaders that are broken' that TU will now try and patch with fixed versions.  Using the TU/Icon/Legacy shader, so some of the transparency stuff might not work (if it needs to work, I'll have to create a new icon shader that supports cutoff transparency).

[Electrocutor]

Just now, Shadowmage said:

Thanks, have added those three to the list of 'stock icon shaders that are broken' that TU will now try and patch with fixed versions.  Using the TU/Icon/Legacy shader, so some of the transparency stuff might not work (if it needs to work, I'll have to create a new icon shader that supports cutoff transparency).

You might consider using a cfg for these, like you did for identifying the transparency shaders. This way you won't have to actually recompile anything between updates when they continue working on updating parts.