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

[UZZO007]

hi, I installed this mod because I was interested in making my game more realistic, but once installed I entered the game and it has remained the same as before, could you tell me why?

[Delay]

2 hours ago, UZZO007 said:

hi, I installed this mod because I was interested in making my game more realistic, but once installed I entered the game and it has remained the same as before, could you tell me why?

That is because the mod only provides an API for other mods to work with. By itself it changes nothing.

[HvP]

6 hours ago, UZZO007 said:

hi, I installed this mod because I was interested in making my game more realistic, but once installed I entered the game and it has remained the same as before, could you tell me why?

You'll need to install a set of configurations that this mod supports.

I recommend using Textures Unlimited Recolour Depot with its Stock Recolour configurations that will allow you to customize your part's colors.

[UZZO007]

Ok thank you very much guys. 

[SilverlightPony]

This mod seems to override the default textures for Procedural Parts; that mod's normal texture-switching function in the VAB/SPH has no effect, and its icons in the parts list are just black silhouettes.  Removing this mod fixed it.

[Electrocutor]

4 hours ago, SilverlightPony said:

This mod seems to override the default textures for Procedural Parts; that mod's normal texture-switching function in the VAB/SPH has no effect, and its icons in the parts list are just black silhouettes.  Removing this mod fixed it.

This mod doesn't do anything. You have installed a configuration file from somewhere that uses this mod that causes the issue. You'll want to let that mod author know so they can look into it. Usually if parts turn black it's because you haven't enabled reflections in the game settings.

 

@Shadowmage I've been tinkering with some blanket implementation and procedural diffuse-to-albedo algorithms, but I've run into some oddities (with stock parts of course). Could you please see if you know what's going on here to give me a direction?

Spoiler

Code:
 

using System;
using UnityEngine;
using UnityEngine.SceneManagement;

namespace TexturesUnlimitedEx
{
    [KSPAddon(KSPAddon.Startup.Instantly, true)]
    public class TexturesUnlimitedEx : MonoBehaviour
    {
        private Shader _TU_Specular;
        private Shader _TU_TransparentSpec;

        public void Start()
        {
            DontDestroyOnLoad(this);
            SceneManager.sceneLoaded += SceneManager_sceneLoaded;
        }

        private void SceneManager_sceneLoaded(Scene oScene, LoadSceneMode oMode)
        {
            if (oScene == null)
            { return; }

            //this._TU_Specular = Shader.Find("TU/Specular");
            //this._TU_TransparentSpec = Shader.Find("TU/Transparent/Specular");

            Shader[] aryShaders = Resources.FindObjectsOfTypeAll<Shader>();

            foreach (Shader oShader in aryShaders)
            {
                if (oShader.name == "TU/Specular")
                { this._TU_Specular = oShader; }
                else if (oShader.name == "TU/Transparent/Specular")
                { this._TU_TransparentSpec = oShader; }
            }

            Material[] aryMaterials = Resources.FindObjectsOfTypeAll<Material>();

            foreach (Material oMaterial in aryMaterials)
            {
                if (oMaterial.shader == null)
                { continue; }

                if (oMaterial.shader.name == "KSP/Diffuse"
                    || oMaterial.shader.name == "KSP/Bumped"
                    || oMaterial.shader.name == "KSP/Bumped Specular"
                    || oMaterial.shader.name == "KSP/Specular"
                    || oMaterial.shader.name == "KSP/Emissive/Diffuse"
                    || oMaterial.shader.name == "KSP/Emissive/Specular"
                    || oMaterial.shader.name == "KSP/Emissive/Bumped Specular")
                {
                    oMaterial.shader = this._TU_Specular;
                    oMaterial.EnableKeyword("TU_STOCK_SPEC");

                    if (oMaterial.GetTexture("_BumpMap") == null)
                    { oMaterial.SetTexture("_BumpMap", Texture2D.normalTexture); }

                    if (oMaterial.GetTexture("_SpecMap") == null)
                    { oMaterial.SetTexture("_SpecGlossMap", Texture2D.blackTexture); }
                    else
                    { oMaterial.SetTexture("_SpecGlossMap", oMaterial.GetTexture("_SpecMap")); }

                    if (oMaterial.shader.name == "KSP/Diffuse"
                        || oMaterial.shader.name == "KSP/Bumped"
                        || oMaterial.shader.name == "KSP/Emissive/Diffuse")
                    { oMaterial.SetFloat("_Smoothness", 0.3f); }
                }
            }
        }
    }
}

Screenshot:

 

Edited April 6, 2020 by Electrocutor

[SilverlightPony]

5 hours ago, Electrocutor said:

This mod doesn't do anything. You have installed a configuration file from somewhere that uses this mod that causes the issue. You'll want to let that mod author know so they can look into it. Usually if parts turn black it's because you haven't enabled reflections in the game settings.

I didn't have *any* separate configuration file installed, as I hadn't yet found one I wanted.  Simply having Textures Unlimited installed interferes with the normal textures and texture-swapping function of the Procedural Parts mod.

The following screenshots were taken from a completely fresh copy of KSP 1.8.1.  The first two are with only Procedural Parts installed.  The next three are with Proc.Parts and Textures Unlimited.

Spoiler

Vanilla + Procedural Parts only.  Note the texture swap function in the part context menu.

 

Now, with Textures Unlimited added:

Note the broken part icons in the left pane, and that the Proc.Parts texture selector no longer works; the new TU system has completely overridden it.

 

[Manwith Noname]

@SilverlightPony

That appears to be working as intended and is not directly a result of Textures Unlimited. If you want to use the original Procedural Parts textures when Textures Unlimited is installed, you'll need to contact the maintainer of the fork you are using and ask them to integrate them in to their patch which is overriding the original assets.

 

Edit: Or make a patch which brings them back.

Edited April 7, 2020 by Manwith Noname

[SilverlightPony]

3 minutes ago, Manwith Noname said:

@SilverlightPony

That appears to be working as intended and is not directly a result of Textures Unlimited. If you want to use the original Procedural Parts textures when Textures Unlimited is installed, you'll need to contact the maintainer of the fork you are using and ask them to integrate them in to their patch which is overriding the original assets.

Edit: Or make a patch which brings them back.

I'll just remove TU until I decide I really want it and can find a suitable PP config/texture-set for it.

[Shadowmage]

17 hours ago, Electrocutor said:

 I've been tinkering with some blanket implementation and procedural diffuse-to-albedo algorithms, but I've run into some oddities (with stock parts of course). Could you please see if you know what's going on here to give me a direction?

Looks like possibly an issue with normal maps?  Try assigning a default normal map to any materials where you replace the shaders...  (why the shaders now require a normal map, and previously would use the default assigned in the property... is likely an under-the-hood change somewhere in Unity...)

[Manwith Noname]

11 hours ago, SilverlightPony said:

I'll just remove TU until I decide I really want it and can find a suitable PP config/texture-set for it.

I just noticed something in your screenshots. There's a new button labelled Legacy Textures with the state disabled, you could try enabling them and see what occurs.

[SilverlightPony]

1 minute ago, Manwith Noname said:

I just noticed something in your screenshots. There's a new button labelled Legacy Textures with the state disabled, you could try enabling them and see what occurs.

Tried that, it makes no difference if TU is installed.  Without TU, that switches between current and previous-version Proc.Parts textures.

Edited April 7, 2020 by SilverlightPony

[Electrocutor]

11 hours ago, Shadowmage said:

Looks like possibly an issue with normal maps?  Try assigning a default normal map to any materials where you replace the shaders...  (why the shaders now require a normal map, and previously would use the default assigned in the property... is likely an under-the-hood change somewhere in Unity...)

I forced all materials to use Texture2D.normalTexture, which is a completely flat default, here is the result:

https://i.imgur.com/deKfXgb.jpg

 

I also noticed that the reflections are 180 degrees off; is that a bug with stock?

[Update]

I think I figured it out. The TU shaders are broken/unbroken if TU_BC5_NRM is not enabled. The exact criteria eludes me yet for when it should be on and when off; as the format of the normal is not the deciding factor.

Can you not use the built-in UnityCG.cginc unpacking?

Perhaps I found the hiccup?

fixed3 normal = UnpackNormalTU(tex2D(_BumpMap, IN.uv_MainTex));

should be

fixed3 normal = UnpackNormalTU(tex2D(_BumpMap, IN.uv_BumpMap));

 

If you want to see the issue yourself, you can also just set the _BumpMap to null or Texture2D.normalTexture so that it will use a completely flat one.

 

Quote

RGBA(107, 153, 250, 255) should become RGBA(255, 153, 153, 107) since Unity 2017.1. Really, the B value is somewhat arbitrary, and can be 0, 255, equal to G, or some other arbitrary data you want to pack into the texture, at the cost of some extra compression artifacts. The reason is, as shown in my last post, Unity multiplied the R and A channels together to get the encoded X, which is how Unity 2017.1 and beyond supports both RG and AG normal encoding.

I wanted to touch on this value a bit more. The way the BC (aka DXTC) compression formats work, the red and blue channels use a 5 bits each and the green channel uses 6 bits for encoding per block color palettes. This means the green value has slightly better precision than red or blue, which is why the Y is left in the green channel. Unity actually stores “DXTn” as (1.0, y, y, x), but the precision difference between the G and B means they might not be perfectly equal when sampled by the shader. I honestly don’t know why they chose to duplicate the Y in the blue channel, but most likely it’s because they used to store it as a greyscale value so all 3 channels held the Y, and changing the red to 1.0 was the smallest change to the existing code. It’s possible some encoders do slightly better when data is duplicated across the RGB channels, but there’s no technical reason the format would do better packed that way.

Assume this is the post-conversion pass you've done, to convert pre 2017.1 normal maps to post 2017.1 the only difference is the red channel is white instead of a copy of the green channel. For the shader change, use the UnpackScaleNormalDXT5nm function instead of the UnpackScaleNormal function and do nothing to the textures and it'll work fine.

i.e. old format must have 1.0 on A, new format must have 1.0 on R, then everything plays along happily together.

Edited April 8, 2020 by Electrocutor

[Shadowmage]

On 4/7/2020 at 9:45 AM, Electrocutor said:

fixed3 normal = UnpackNormalTU(tex2D(_BumpMap, IN.uv_BumpMap));

I don't have separate UV scaling for main vs other textures; I use a single scaling across all, to reduce the number of shader properties.

On 4/7/2020 at 9:45 AM, Electrocutor said:

Can you not use the built-in UnityCG.cginc unpacking?

Nope, because KSP normal map textures are not authored properly or consistently, they fail when using the built-in decoding.

 

Some things to think on though...  I can certainly open up some additional properties for the UV scaling/offsets for normal maps, as I could possibly see some use of that for some effects. 

Fixing the stock normal map inconsistent encoding though, well, I also added a config-based system so you can do that yourself (it will fix the textures during loading, however it adds 0.25 - 2s per texture to be fixed, depending on texture size).  Let me know if interested and I'll look into some documentation on the feature.

[Electrocutor]

How did I not know that TU supported emissive lighting?

[Manwith Noname]

@Electrocutor If you're referring to the cabin lights "shining" on to other parts of the pod, it's artistic use of the emissive texture itself.

[Agustin]

Hello.. How can I make transparent parts? like for example procedural wings...? It seems on the last page of recolour depot thread someone has that...

Edited April 9, 2020 by Agustin

[Manwith Noname]

@Agustin

I know you want it but it might be best to just wait and see if they give you a link to the download. Essentially someone took the pWings parts and made new ones with different material properties and textures. Kinda like TU does without all the external work but it's worth highlighting, they don't use TU.

Can you do something similar with TU? Kinda...

Spoiler

That's just a quick hack but TU's translucent shaders are something I have been struggling with for a while now.

[Delay]

7 hours ago, Manwith Noname said:

That's just a quick hack but TU's translucent shaders are something I have been struggling with for a while now.

The TU/transparent/ shader doesn't seem to work properly, look back a few pages where I discussed the problem with @Shadowmage.

While I'm at it, would it be outrageous if I asked what the situation currently looks like?
Out of curiosity, I don't want to press or anything. I realize these things take a lot of time, effort and patience.

Edited April 9, 2020 by Delay

[Manwith Noname]

2 hours ago, Delay said:

The TU/transparent/ shader doesn't seem to work properly, look back a few pages...

Hehe, yeah, I know. When I say "a while", I'm talking years. It's why i don't currently touch launch clamps, parachutes and...various things I can't really mention right now due them being projects not revealed. Way back in the early days of this thread there should be a discussion about it from memory.

I'm sure it's a nut that will get cracked one day. I had revisited a problem with regard to this just recently and I'm gathering more information that might be useful in identifying where things go wrong.

[Electrocutor]

The TU transparent shader is locked into zwrite=true, srcblend=alpha, dstblend=oneminusalpha, and doesn't have a cutoff option. This can lead to some cases where it doesn't work.

[Manwith Noname]

@Electrocutor

Yeah, an alpha cutoff shader is what I've been after for a long time, it's what you really want for the launch clamps, parachutes and other cases. The translucency shaders have their place too though and I've also been trying to use them as intended previously. Here's a composite of the various issues I've encountered previously but with a modified pWings part...

Spoiler

From left to right, showing that reflections and spec works fine in the editor. Next slice is to show how the shine is lost in the flight scene. Third slice is to show the disappearance of almost everything at certain camera distances. Last is to show odd behaviour with regard to world scenery.

[Shadowmage]

On 4/8/2020 at 9:42 PM, Manwith Noname said:

That's just a quick hack but TU's translucent shaders are something I have been struggling with for a while now.

Understandable.  I know close to nothing about transparency/etc, so whatever I've implemented is likely either too simplistic for all cases, or simply wrong.

(I never use transparency, not even a single time in my years of modding, so I've never had a reason to learn about its use in shaders and how they should be setup, hence the current situation)

 

What I really need, is someone who is an expert at Unity transparent shaders that wouldn't mind giving some input on what needs to be changed in the shaders to make them workable for all situations (and still be usable from within KSP).

On 4/9/2020 at 8:47 AM, Electrocutor said:

The TU transparent shader is locked into zwrite=true, srcblend=alpha, dstblend=oneminusalpha, and doesn't have a cutoff option. This can lead to some cases where it doesn't work.

What would be the needed settings to lead to it working in all cases?  (is there a single set of values that work universally?)

 

9 hours ago, Manwith Noname said:

Yeah, an alpha cutoff shader is what I've been after for a long time, it's what you really want for the launch clamps, parachutes and other cases.

Could possibly make a new alpha-cutoff shader variant, wouldn't be too hard -- but what other settings/values does it need for the zwrite/ztest/blending/etc?

 

Willing to work on fixing these issues, but I'm going to need some very specific input on what needs to be done, as honestly, I don't care to spend hours 'learning all about transparent shaders', when I'll never end up using them.

[Manwith Noname]

@Shadowmage

Alright, I'm prepared to do some reading and spitball what I find but this might be no use as I'm not a programmer or shader guru (need that bgolus person from the Unity forums that seems to appear in all the threads I read).

I could be completely wrong but I don't think you can make a one size fits all shader. For an alpha cutoff shader you want:

// inside SubShader
Tags { "Queue"="AlphaTest" "RenderType"="TransparentCutout" "IgnoreProjector"="True" }

// inside CGPROGRAM in the fragment Shader:
clip(textureColor.a - alphaCutoffValue);

...according to this. Also on that page, maybe, might be worth implementing as alpha to coverage instead so MSAA can tidy things up. I suppose it would be handy to see inside what KSP/Alpha/Cutoff and the bumped variant use as that's what is applied to stock parts like the launch clamps and parachutes plus quite commonly in mods using blur textures.

I also found something that hints at ways to improve the translucency shader so that making a part glass like is represented better here. Primarily, the part right at the bottom with regard to using two passes so the back faces should be rendered.

I've also been thinking about altering the shadow strength and colour based on the translucency and shade of the part but so far I've come up short.

[VoidCosmos]

@Shadowmage

How do you write a Textures Unlimited config so as to making a part 'white'?