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

[Delay]

5 minutes ago, Shadowmage said:

I'de much prefer to just use it rather than making something new with the same features.

if the system is more efficient or otherwise better I'd say go for it.

[pap1723]

Hello Shadow,

Working on 1.4.4 and having some user errors (PEBKAC for sure)

I am getting this error:

ERROR: Could not locate texture set for name: procDefault

Module KSPTextureSwitch threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at KSPShaderTools.TextureSetContainer.getTextureSetNames () [0x00000] in <filename unknown>:0 
  at KSPShaderTools.KSPTextureSwitch.initialize () [0x00000] in <filename unknown>:0 
  at KSPShaderTools.KSPTextureSwitch.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 

Here is part of the config, cannot figure out what I am doing wrong.

// Add the PartModule for switching textures to all procedural part tanks
@PART[proceduralTankLiquid|proceduralTankOre|proceduralTankSRB|proceduralTankXenon|proceduralTanksRealFuels]:FOR[zzzProcUnlimited]
{
    MODULE
    {
        name = KSPTextureSwitch
        sectionName = Procedural Tank
        currentTextureSet = procDefault   // Start with the most basic one
        
        // Each textureSet is a specific set of textures that can be selected in the UI
        textureSet = procDefault
		textureSet = Stringer-S
		textureSet = InsulatedPlain
		textureSet = Metallic
    }
	MODULE
	{
		name = SSTURecolorGUI
	}
}

// This is an individual texture set
KSP_TEXTURE_SET
{
    name = procDefault
    title = Default
    recolorable = true
    MATERIAL
    {
        //shader = SSTU/PBR/Metallic
		shader = SSTU/PBR/Masked
        texture = _MainTex,         ProcUnlimited/Textures/Default
        texture = _BumpMap,         ProcUnlimited/Normals/Smooth-NRM
        texture = _MetallicGlossMap,ProcUnlimited/Metallic/Smooth-M-MET
        texture = _MaskTex,         ProcUnlimited/Masks/Plain-MASK
        keyword = TU_RECOLOR
        vector = _DiffuseNorm,      0.5,0.5,0.5
		vector = _MetalNorm,        0.5,0.5,0.5
		vector = _SmoothnessNorm,   0.5,0.5,0.5
    }
    COLORS
    {
        mainColor = white
        //secondColor = black
        //detailColor = steel
    }
}

As usual, your help is greatly appreciated!

[Shadowmage]

18 hours ago, pap1723 said:

Hello Shadow,

Working on 1.4.4 and having some user errors (PEBKAC for sure)

I am getting this error:

ERROR: Could not locate texture set for name: procDefault

Module KSPTextureSwitch threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at KSPShaderTools.TextureSetContainer.getTextureSetNames () [0x00000] in <filename unknown>:0 
  at KSPShaderTools.KSPTextureSwitch.initialize () [0x00000] in <filename unknown>:0 
  at KSPShaderTools.KSPTextureSwitch.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 

Here is part of the config, cannot figure out what I am doing wrong.

// Add the PartModule for switching textures to all procedural part tanks
@PART[proceduralTankLiquid|proceduralTankOre|proceduralTankSRB|proceduralTankXenon|proceduralTanksRealFuels]:FOR[zzzProcUnlimited]
{
    MODULE
    {
        name = KSPTextureSwitch
        sectionName = Procedural Tank
        currentTextureSet = procDefault   // Start with the most basic one
        
        // Each textureSet is a specific set of textures that can be selected in the UI
        textureSet = procDefault
		textureSet = Stringer-S
		textureSet = InsulatedPlain
		textureSet = Metallic
    }
	MODULE
	{
		name = SSTURecolorGUI
	}
}

// This is an individual texture set
KSP_TEXTURE_SET
{
    name = procDefault
    title = Default
    recolorable = true
    MATERIAL
    {
        //shader = SSTU/PBR/Metallic
		shader = SSTU/PBR/Masked
        texture = _MainTex,         ProcUnlimited/Textures/Default
        texture = _BumpMap,         ProcUnlimited/Normals/Smooth-NRM
        texture = _MetallicGlossMap,ProcUnlimited/Metallic/Smooth-M-MET
        texture = _MaskTex,         ProcUnlimited/Masks/Plain-MASK
        keyword = TU_RECOLOR
        vector = _DiffuseNorm,      0.5,0.5,0.5
		vector = _MetalNorm,        0.5,0.5,0.5
		vector = _SmoothnessNorm,   0.5,0.5,0.5
    }
    COLORS
    {
        mainColor = white
        //secondColor = black
        //detailColor = steel
    }
}

As usual, your help is greatly appreciated!

The older shaders you are working with (1.3.x) don't use/support the 'vector=' syntax or the 'norm' properties.  Likely it is erroring (why does spell check not recognize that word?) out when parsing the texture set definition, and thus the texture set cannot be loaded, and finally it then cannot be found when attempting to apply it to a part.

If that does not clean it up -- mind putting up a KSP.log file?  Likely some hints as to what is going on in there.

[pap1723]

48 minutes ago, Shadowmage said:

The older shaders you are working with (1.3.x) don't use/support the 'vector=' syntax or the 'norm' properties.  Likely it is erroring (why does spell check not recognize that word?) out when parsing the texture set definition, and thus the texture set cannot be loaded, and finally it then cannot be found when attempting to apply it to a part.

If that does not clean it up -- mind putting up a KSP.log file?  Likely some hints as to what is going on in there.

Ah, I was testing on 1.4.5 and was using the TU that I thought was for that version. I did not see the new shaders in the config there yet. I will test it out and let you know!

[pap1723]

OK, so I will preface this by saying I should not be messing with textures because apparently, I have no idea what I am doing... That being said as I do not understand the Alpha layer at all. Can anyone give me a little bit of help on how to best setup a DIFF where I want the Color Mask to fully take over (except for some of the details) and a Metallic Mask that doesn't turn my model into a crazy metal object. I looked at the WIki from TU, but apparently was not smart enough to know what you were talking about.

Thanks in advance to help out a NEWB.

[Shadowmage]

20 minutes ago, pap1723 said:

OK, so I will preface this by saying I should not be messing with textures because apparently, I have no idea what I am doing... That being said as I do not understand the Alpha layer at all. Can anyone give me a little bit of help on how to best setup a DIFF where I want the Color Mask to fully take over (except for some of the details) and a Metallic Mask that doesn't turn my model into a crazy metal object. I looked at the WIki from TU, but apparently was not smart enough to know what you were talking about.

Thanks in advance to help out a NEWB.

I'm inferring that you are wanting to create 'Recolorable' textures based on your comment.  These are not authored in the same fashion as other textures (and do not require alpha channels for transparency, but do).

1. Create your diffuse + detail texture.  It should have a base color of 127,127,127, with minor highlights/shadows for detail/noise.  Users' selected values will control the base/albedo color for the pixels.
2. Create your specular texture.  As with the diffuse, it should be 127,127,127, with minor highlights/shadows for detail/noise. Users' selected values will control the 'smoothness' of any given pixel.
3. Create your metallic texture.  As with the diffuse, it should be 127,127,127, with minor highlights/shadows for detail/noise.  Users' selected values will control if any specific pixel is metal or not.
4. Create your RGB mask texture, with each color representing one recoloring section/channel.  Any portion that is BLACK in your recolor mask should be 'normal' in the diff/spec/metal textures; any portion that is not pure black in your recolor mask should be base gray in the diff/spec/metal textures.
5. PUT THE SPECULAR TEXTURE INTO THE ALPHA CHANNEL OF THE METALLIC TEXTURE  (from your comments, this is what is being problematic to you?)  R = metallic data, G = occlusion/AO data, A = specular data
   1. Depending on what version of the shaders you are targeting, this may be backwards. 
      • 1.3.1 shaders -- R = specular, A = metallic. 
      • 1.4.x+ shaders -- R = metallic, A = specular
6. Create your texture-set configs, referencing each of the textures for the relevant texture-slots in the shader.  If recolorable, make sure to mark the texture set as 'recolorable = true' + include the COLORS block.

What/where are your problems occurring in the above sequence?  (if I know what part of the information is not clear, I can attempt to clean up the tutorials/info on the wiki;  this is all just simple texture-work and should be doable following the information on the wiki)

 

If all else fails -- please post up examples of your current DIFF, SPEC, METAL, and MASK textures and the texture-set config, so that I might see what is going on/what is wrong.

Edited December 11, 2018 by Shadowmage

[pap1723]

Thank you once again Shadow! This makes things very clear!

Now when I am setting my _DiffuseNorm, _MetalNorm and _SmoothnessNorm I understand that they represent the RGB values? I noticed that for your SSTU Texture Set, you have all of them essentially set at 0.5. What do smaller and larger numbers represent?

[Shadowmage]

Just now, pap1723 said:

Thank you once again Shadow! This makes things very clear!

Now when I am setting my _DiffuseNorm, _MetalNorm and _SmoothnessNorm I understand that they represent the RGB values? I noticed that for your SSTU Texture Set, you have all of them essentially set at 0.5. What do smaller and larger numbers represent?

First -- what version are you working with?  Previously it looked like you were working on older versions for RP-0 (which don't support the normalization features).

If working with older versions -- what I wrote above is mostly correct.

If working with newer versions -- completely different methods available to author textures (using the _XXXNorm parameters), though the above listed methods will still work (with custom norm values).

[pap1723]

1 minute ago, Shadowmage said:

First -- what version are you working with?  Previously it looked like you were working on older versions for RP-0 (which don't support the normalization features).

If working with older versions -- what I wrote above is mostly correct.

If working with newer versions -- completely different methods available to author textures (using the _XXXNorm parameters), though the above listed methods will still work (with custom norm values).

I was working with the older stuff for 1.3.1, but then decided that I didn't want to design something for that when we will be moving forward. I just recently updated to the newest version of TU that works for both 1.5 and 1.4.5 for me without conflict.

[Shadowmage]

Just now, pap1723 said:

I was working with the older stuff for 1.3.1, but then decided that I didn't want to design something for that when we will be moving forward. I just recently updated to the newest version of TU that works for both 1.5 and 1.4.5 for me without conflict.

Ahh, okay then.  Actually makes things eaiser.

Go ahead and make your textures however you want (they don't need to be gray), and once done, post links to the diffuse/metallic/specular textures, and I can tell you what the _XXXNorm parameters should be/how to calculate them.  In this setup you will want your _MetallicGlossMap to have metallic data in the R channel, and smoothness/specular in the A channel.  If you need help figuring that bit out, let me know and I can provide some instructions and/or a tool to help.

[Shadowmage]

1.6 Update News:

I will be investigating the changes to stock code and its in-flight reflection handling that were done in 1.6, use their system if possible, but otherwise update/fix/override whatever is necessary to make the two work together well.  As such, it is going to take a bit of time for this to be done.  I would anticipate one to three weeks, depending on how quirky the stock implementation is.

I have not yet personally tested, but reports tell me that TU appears to work fine in 1.6 (in OpenGL on a Mac at least), so if the current versions work for you, go ahead and use them.  At this time there are no scheduled changes to the plugin aside from potential bugfixes and the stock reflection-updating, so there should not be any concern of game-breakage when the update is released.  (I did have some very substantial stuff planned, but was anticipating another few weeks to work on it).

[ssd21345]

<snip> 

seems module manager problem

Edited December 24, 2018 by ssd21345

[Shadowmage]

Finally got a chance to investigate KSP 1.6 and its 'in-flight environment reflection updates'.  It appears that they have chosen to utilize the Unity Reflection Probe for updates, which is logical as there really isn't any other way to do it.

The good news is that the stock system is inherently compatible with TU shaders, and that it can be disabled entirely through the in-game stock Settings menu.

The bad news is that the stock system is not entirely compatible with Scatterer (untested, but likely EVE as well).  Or rather, Scatterer is incompatible with Unity Reflection Probes.

 

At this point there is potentially a choice to make:

• Disable/remove TU's reflection system in favor of the stock system (problems included)
• Keep TU's reflection system in-place, allow player to choose stock or TU reflection systems
• Hack around with the stock reflection system to utilize its reflection probe, but with the TU 'fixes' in place
• ???  (open to suggestions)

For the time being I'll likely be leaving the TU system in place, but add some quick checks to disable it if the stock reflection updates are enabled (no reason to have both going).  I'll give some time to see how Scatterer and EVE respond to the stock reflection system.  Would really rather love to not have to do the hacky (and bad for performance) fixes that are in place, all of which exist because Scatterer and EVE have issues when the Unity Reflection Probes are used.

[Ger_space]

Keeping the stock system as it is and make it switchable between TU and stock sounds a reasonable approach to me. 

The new stock implementation it's just to new to be messed with. 

Maybe scatterer and eve will adjust, or people running with the two. mods will install TU anyway, because they run dx11 and need the shader fix. 

Trying to fix the stock implementation is probably going to be a more extensive research project, that should not be done, when you have the feeling, that you are being in schedule. 

 

[pap1723]

On 12/11/2018 at 1:00 PM, Shadowmage said:

Ahh, okay then.  Actually makes things eaiser.

Go ahead and make your textures however you want (they don't need to be gray), and once done, post links to the diffuse/metallic/specular textures, and I can tell you what the _XXXNorm parameters should be/how to calculate them.  In this setup you will want your _MetallicGlossMap to have metallic data in the R channel, and smoothness/specular in the A channel.  If you need help figuring that bit out, let me know and I can provide some instructions and/or a tool to help.

Hi Shadow,

I have started to look at this again as we near release for 1.4.5+ and I was hoping I could still get your help. I have attached the files I want to use to make up one of the texture sets we will have. Can you let me know how to organize them to work best with TU? I have access to GIMP and Photoshop and I can see the different channels, but as a graphics idiot, I am not positive how to manipulate them properly. For example anytime I put textures into an Alpha channel, it just changes the transparency.

Thanks!

These are all based on the SSTU ones. I want to essentially simulate what you have with SSTU where the textures do not have any color, the color is all dictated by the Color Switching GUI setup.

Mask: https://github.com/pap1723/ProcUnlimited/blob/master/GameData/ProcUnlimited/Masks/Redstone-L-MASK.png

Metallic: https://github.com/pap1723/ProcUnlimited/blob/master/GameData/ProcUnlimited/Metallic/Smooth-L-MET.png

Normal: https://github.com/pap1723/ProcUnlimited/blob/master/GameData/ProcUnlimited/Normals/Smooth-NRM.png

Texture: https://github.com/pap1723/ProcUnlimited/blob/master/GameData/ProcUnlimited/Textures/Default.png

[Alioth81]

Is it possible to influence the order in which textures are overwritten so that TU is last?

I tried to make this work for the procedural parts mod for 1.5.1

In the same way TURD does it for Stock parts.

Basically it works in the VAB and you can switch textures and use the repaint Ui

Once you load the flight scene it reverts to the last selected procedural parts texture.

If the texture config file of procedural parts is deleted. The switched and colored TU texture stays also in the flight scene as the orocedural parts mod thinks there is no texture available.

So it overwrites the TU textures.

 

[pap1723]

3 hours ago, Alioth81 said:

Is it possible to influence the order in which textures are overwritten so that TU is last?

I tried to make this work for the procedural parts mod for 1.5.1

In the same way TURD does it for Stock parts.

Basically it works in the VAB and you can switch textures and use the repaint Ui

Once you load the flight scene it reverts to the last selected procedural parts texture.

If the texture config file of procedural parts is deleted. The switched and colored TU texture stays also in the flight scene as the orocedural parts mod thinks there is no texture available.

So it overwrites the TU textures.

 

Hi @Alioth81
I have been working on creating TU support for Proc Parts as well. I have a repo but will be resuming work on it soon. See here: https://github.com/pap1723/ProcUnlimited

 

[Shadowmage]

23 hours ago, pap1723 said:

Hi Shadow,

I have started to look at this again as we near release for 1.4.5+ and I was hoping I could still get your help. I have attached the files I want to use to make up one of the texture sets we will have. Can you let me know how to organize them to work best with TU? I have access to GIMP and Photoshop and I can see the different channels, but as a graphics idiot, I am not positive how to manipulate them properly. For example anytime I put textures into an Alpha channel, it just changes the transparency.

Thanks!

These are all based on the SSTU ones. I want to essentially simulate what you have with SSTU where the textures do not have any color, the color is all dictated by the Color Switching GUI setup.

Mask: https://github.com/pap1723/ProcUnlimited/blob/master/GameData/ProcUnlimited/Masks/Redstone-L-MASK.png

Metallic: https://github.com/pap1723/ProcUnlimited/blob/master/GameData/ProcUnlimited/Metallic/Smooth-L-MET.png

Normal: https://github.com/pap1723/ProcUnlimited/blob/master/GameData/ProcUnlimited/Normals/Smooth-NRM.png

Texture: https://github.com/pap1723/ProcUnlimited/blob/master/GameData/ProcUnlimited/Textures/Default.png

Do you have a Smoothness / Gloss texture?  Seems to be the only one missing.   (or is it already in the alpha channel of the MET?)

Should have five(six?) source textures, which are then compressed into four binary assets to be referenced in the configuration file
DIFF  (its own RGB)
SMOOTH (A channel in MET)
MET (R channel in MET)
AO (G channel in MET)
NRM (RGB)
MASK (RGB)

The textures that I've looked at appear to be correct for the grayscale based setup.  As soon as the smoothness/channel stuff is figured out, you should be able to simply write a config to reference them all and apply them to parts.

 

20 hours ago, Alioth81 said:

Is it possible to influence the order in which textures are overwritten so that TU is last?

No.  If you need to interact with other plugins, you will have to write your own custom plugin in order to do so (or have that plugins authors make the required changes).

E.G.  TU -> PP -> Your Custom Stuff

In short -- TU is not intended to be able to change procedural parts, nor is it intended to work alongside any other texture-switches.  If you need such functionality, you will have to write your own custom plugin code to do it.

[Alioth81]

Thanks for the answer @Shadowmage

I thought that their texture switching would probably interfere but I hoped for an easy way out

@pap1723

You have some beautiful textures - I just tried quick and dirty if it is easily doable with a simple MM configuration and as I am not really a programmer it ends here for me.

You currently use your side textures also for the end caps. if you add an excludeMesh = ends it will use the PP parts texture or you create also nice looking end caps.

If you are fast at creating also the procedural wings could use some TU textures  

However I think you will face the same problems I had and the textures will not be persistent once you go to the flight scene.

It would probably be best if the maintainers of the procedural parts/wings would integrate a MM configurable switch to disable their texture switching/handling system but i have no idea how easy that is.

[Shadowmage]

10 minutes ago, Alioth81 said:

I thought that their texture switching would probably interfere but I hoped for an easy way out

Indeed.  Sadly, any 'easy way out' would have to come from the PP end of things, in the fashion of something in the configs that would turn off their texture-assignments entirely.

11 minutes ago, Alioth81 said:

It would probably be best if the maintainers of the procedural parts/wings would integrate a MM configurable switch to disable their texture switching/handling system but i have no idea how easy that is.

^^ Pretty much this exactly.  As a bonus, such a solution coming from PP itself would allow for turning off/disabling of any PP texture-switch UI widgets, and result in less part-action-window clutter.

The other alternative would be a custom PartModule that interfaced with the existing TU part-module, but re-applied the textures at a later point in the loading sequence.  Could probably end up being quite simple, something like 5-10 lines of functional code.

Hmm... thinking on it a bit (but not being familiar with the PP code), this might be solvable with an order-of-patching thing.  What does the final config for the PP parts look like, post-MM patches?  If the TU texture-switch part-module is the last module on the part, it should run its updates after all of the others (assuming that the updates are being done in the same lifecycle calls between the two mods; e.g. both are using OnStart).

[pap1723]

22 hours ago, Shadowmage said:

Indeed.  Sadly, any 'easy way out' would have to come from the PP end of things, in the fashion of something in the configs that would turn off their texture-assignments entirely.

^^ Pretty much this exactly.  As a bonus, such a solution coming from PP itself would allow for turning off/disabling of any PP texture-switch UI widgets, and result in less part-action-window clutter.

The other alternative would be a custom PartModule that interfaced with the existing TU part-module, but re-applied the textures at a later point in the loading sequence.  Could probably end up being quite simple, something like 5-10 lines of functional code.

Hmm... thinking on it a bit (but not being familiar with the PP code), this might be solvable with an order-of-patching thing.  What does the final config for the PP parts look like, post-MM patches?  If the TU texture-switch part-module is the last module on the part, it should run its updates after all of the others (assuming that the updates are being done in the same lifecycle calls between the two mods; e.g. both are using OnStart).

Probably a strange question @Shadowmage but will TU get angry if I have a normal map that is a different size (different dimensions) from a DIFF and a MASK?

[Shadowmage]

1 hour ago, pap1723 said:

Probably a strange question @Shadowmage but will TU get angry if I have a normal map that is a different size (different dimensions) from a DIFF and a MASK?

Nope, TU doesn't care about texture resolutions at all.  It will simply take the texture you specify and put it into the shader slot for the material; it won't even check formats/etc.

[pap1723]

1 minute ago, Shadowmage said:

Nope, TU doesn't care about texture resolutions at all.  It will simply take the texture you specify and put it into the shader slot for the material; it won't even check formats/etc.

Great! Thank you, this will save a lot of memory and work.

[pap1723]

Hey @Shadowmage

I have been working on some more textures and applying them to Procedural Parts. Here is a request I have for TU: Can you make it so the Texture Sets can be created (to a degree) in the editor menu? What I am really looking for is the ability to choose a NRM, DIFF and MASK as selectable options. The base MET, SMOOTH and AO would all stay static, but the rest could be built on demand.

This is what I am trying to accomplish, you might have a better way to do it...

So I have a MASK that I call Checkers. It is a simple 2x2 grid that has a checkered pattern similar to the early V-2 rockets. With the way procedural parts works, I would love if these could be combined with other options. So I want to have the checkered available with a Smooth (no bump) Normal, a Stringers Normal, a Foam Normal, etc.

If TU already has this functionality (and can build the texture sets somewhat on demand) then can you point me to the spot in the code I should look at to call externally so I could build this on demand into Procedural Parts?

THANKS!
Pap

[Shadowmage]

On 1/12/2019 at 7:30 PM, pap1723 said:

If TU already has this functionality (and can build the texture sets somewhat on demand) then can you point me to the spot in the code I should look at to call externally so I could build this on demand into Procedural Parts?

TU does not already have such functionality, though what you are looking for has been brought up a few other times in regards to custom texture packs / recoloring, and it is a feature I would like to have.  The problems arise in that it is such a huge difference from the existing methods that neither the existing UI nor the plugin code could properly accomodate it (with the UI being perhaps the more difficult of the problems to solve).

With that said -- I will certainly give it some consideration during the upcoming UI redesign (whenever that actually happens...).  There are a few other features and changes coming regarding the recoloring and customization end of the mod, and I think the end result will be... well.. something different at least.

If you were up for some custom plugin coding... it might be possible to do what you are looking for by leveraging some of the existing TU infrastructure... but I make no guarantees.  I've been out of the loop for a bit, and would have to re familiarize myself with the code base before I could say for certain, or give any more pointed tips on where to start.  At the end of the day though, the shaders and reflection updates are the important parts provided by TU -- all else is provided only for convenience for the most common use-cases (or what was seen as the most common at the original time of development); it is fully possible to leverage the shaders with fully custom plugin code that doesn't touch any of the other TU TextureSet stuff.