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

[Shadowmage]

13 hours ago, Thorn_Ike said:

I'm still pretty confused as to how to install and get this thing working. I've put 000_TexturesUnlimited and KSPF from Electrocutor's thread into my GameData, but I don't see any button on my toolbar to open up the Part Recoloring GUI. Have I installed something wrong, am I missing a keybinding, am I just blind and forgot something? Please help out here, thanks.

The recoloring button is present on individual parts (in their right-click menu), and only those parts that have been patched to support it.

[Thorn_Ike]

6 hours ago, Shadowmage said:

The recoloring button is present on individual parts (in their right-click menu), and only those parts that have been patched to support it.

Is there a list to which parts support it?

[Shadowmage]

14 minutes ago, Thorn_Ike said:

Is there a list to which parts support it?

You'll have to get that information from whichever config/patch sets you have installed.  At this time I do not include any patch-sets with the mod, but there are a couple linked on the front page from other authors.

If you haven't installed any patch-sets, then there will be nothing to list.  (installing TU, by itself, does nothing; it relies on mod authors to provide their own configuration files or patches)

The 'easiest' way to get recolorable parts is to install SSTU ( https://forum.kerbalspaceprogram.com/index.php?/topic/117090-wip17x-sstulabs-low-part-count-solutions-orbiters-landers-lifters-dev-thread-11-18-18/ ), and use the parts that it provides.  Pretty much the entire mod supports recoloring.

Aside from that there is TexturesUnlimitedRecoloringDepot that provides patches for stock and a few mods' parts (may be a bit out of date, but should mostly work) -- https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/

Unfortunately not many mod authors have been receptive to creating or providing TU patches or configs.

Please let me know if there was any more information I could provide;

[Thorn_Ike]

1 hour ago, Shadowmage said:

You'll have to get that information from whichever config/patch sets you have installed.  At this time I do not include any patch-sets with the mod, but there are a couple linked on the front page from other authors.

If you haven't installed any patch-sets, then there will be nothing to list.  (installing TU, by itself, does nothing; it relies on mod authors to provide their own configuration files or patches)

The 'easiest' way to get recolorable parts is to install SSTU ( https://forum.kerbalspaceprogram.com/index.php?/topic/117090-wip17x-sstulabs-low-part-count-solutions-orbiters-landers-lifters-dev-thread-11-18-18/ ), and use the parts that it provides.  Pretty much the entire mod supports recoloring.

Aside from that there is TexturesUnlimitedRecoloringDepot that provides patches for stock and a few mods' parts (may be a bit out of date, but should mostly work) -- https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/

Unfortunately not many mod authors have been receptive to creating or providing TU patches or configs.

Please let me know if there was any more information I could provide;

I've been trying to get this GUI to show up: 

(badly cropped from a beacoupzero video but you get the idea)
He was using this on a MK1 cockpit, and he had this button:

I, however, haven't been able to get it to show up. I have installed TU and Electrocutor's KSPF, is there something I'm missing here?

[Shadowmage]

15 hours ago, Thorn_Ike said:

I have installed TU and Electrocutor's KSPF, is there something I'm missing here?

Link to that patch set?

When I last looked at Electrocutor's patches, he wasn't distributing any 'general' patches anymore that I saw, only for specific mods.  (At one point, yes, he had a patch set that would add a form of recoloring to nearly all stock parts)

[Thorn_Ike]

4 hours ago, Shadowmage said:

Link to that patch set?

When I last looked at Electrocutor's patches, he wasn't distributing any 'general' patches anymore that I saw, only for specific mods.  (At one point, yes, he had a patch set that would add a form of recoloring to nearly all stock parts)

I used this link: 

 

[Shadowmage]

6 minutes ago, Thorn_Ike said:

I used this link: 

I'm not seeing any TexturesUnlimited patch sets there, except for links specifically for Procedural Fairings and Feline Rovers.  The KSPF mod from that page is something else entirely, and not related to TU or recoloring.

 

You might have more luck trying the patches from here: 

https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/

But keep in mind, those are quite a bit out of-date last I checked, and I cannot guarantee that they will work entirely.

 

On that note, I am slowly working on putting together a proper patch+texture set that adds basic recoloring to stock parts, but it is very early in the design process.  It is based on the mask textures from the link above, but provides entirely new configs that utilize the latest TU shaders and features.  I might start offering downloads of this in the near future while it is still in development after I get a few more parts added (possibly even sometime over the weekend); if so, I'll post links here.  No guarantees though as I'm still determining if I want to do WIP releases, and even if this is something that I want to continue to completion  (currently at part #21 out of 327).

[Thorn_Ike]

2 hours ago, Shadowmage said:

I'm not seeing any TexturesUnlimited patch sets there, except for links specifically for Procedural Fairings and Feline Rovers.  The KSPF mod from that page is something else entirely, and not related to TU or recoloring.

 

You might have more luck trying the patches from here: 

https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/

But keep in mind, those are quite a bit out of-date last I checked, and I cannot guarantee that they will work entirely.

 

On that note, I am slowly working on putting together a proper patch+texture set that adds basic recoloring to stock parts, but it is very early in the design process.  It is based on the mask textures from the link above, but provides entirely new configs that utilize the latest TU shaders and features.  I might start offering downloads of this in the near future while it is still in development after I get a few more parts added (possibly even sometime over the weekend); if so, I'll post links here.  No guarantees though as I'm still determining if I want to do WIP releases, and even if this is something that I want to continue to completion  (currently at part #21 out of 327).

Aha! That did the trick, thanks!

[ISOREX_]

Hi, I am having a minor issue with TU. In the VAB and SPH, the parts in the editor list are clipping through the bottom. Does anyone know how to fix this? 

EDIT: I know see that this is an older issue that should've been fixed. To add a bit more information I'm playing on OSX, latest version of KSP.

Edited July 21, 2019 by ISOREX_

[Shadowmage]

4 hours ago, ISOREX_ said:

Hi, I am having a minor issue with TU. In the VAB and SPH, the parts in the editor list are clipping through the bottom. Does anyone know how to fix this? 

EDIT: I know see that this is an older issue that should've been fixed. To add a bit more information I'm playing on OSX, latest version of KSP.

Thanks for the report.  Indeed, is a bit of a 'known issue' regarding shaders with OpenGL (OSX/Linux).  I -thought- I had it fixed in the latest versions, but apparently may have missed something.  Can you confirm that you are using the latest version of TU?

And is it only a few specific parts, or most/all parts?

[ISOREX_]

26 minutes ago, Shadowmage said:

Thanks for the report.  Indeed, is a bit of a 'known issue' regarding shaders with OpenGL (OSX/Linux).  I -thought- I had it fixed in the latest versions, but apparently may have missed something.  Can you confirm that you are using the latest version of TU?

And is it only a few specific parts, or most/all parts?

I am using the latest version from GitHub, version 1.4.8.22. So far it looks like it is for all parts, and I also noticed that the top row of icons is missing the top half of the icon.

Here's a picture where you can see it, as I am not the best at explaining.

[Shadowmage]

20 hours ago, ISOREX_ said:

I am using the latest version from GitHub, version 1.4.8.22. So far it looks like it is for all parts, and I also noticed that the top row of icons is missing the top half of the icon.

Thanks for the confirmation.  Yeah, that looks like the same icon-shader issues that I thought I had cleaned up.

What happens is that screen coordinates are inverted in OpenGL, and the icon-shader relies on screen coordinates to set up some screen-space based clipping.  At various times KSP has passed in regular coordinates, or pre-inverted coordinates, so I've played a bit of whack-a-mole with trying to keep up with their 'fixes'.  To make things more complicated, KSP manipulates things in plugin code, but I have to somehow handle it all entirely on the internals of the shader-side of things.  Fun stuff

(wanted to open an issue on Github to track it, but apparently Github doesn't want to load the TU repo at the moment; I'll try and remember to open the ticket later).

 

 

In general development news... I finally decided to sit down and create some real examples/configs of how the recoloring system is intended to be used.  This set of configs and textures will provide:

• Examples of adding recoloring to existing stock/mod parts.
• Examples of use of TU with the stock part-variant system.
• Examples of use of the 'normalization' system for recoloring, which allows use of existing textures and faithful color reproduction between different models and base textures
• Show how to add texture sets and texture-switching to parts without messing up existing shader parameters, without using MODEL_SHADER, and allowing drop-in compatibility with existing save-games.
• Near-complete set of configs and textures to add recoloring to Stock (non-DLC) parts.

The initial set of masks are based on those from TURD, which I believe have evolved from KerbPaint originally, used under the terms of the licenses.  I'll likely be redoing and replacing several of these masks, and will be creating quite a few new masks for parts that were lacking them (mostly the reworked stock parts).  Would not have been possible without those mask textures (or at least would not have been a project I would consider undertaking), so if you enjoy these patches/configs, please send some 'thanks' towards those authors.

The first pass of the project is done -- configs have been written for every part for which a mask texture existed (204 out of 305 total parts; took about ~25 hours).  Next pass is calculating normalization data for all of these, which should be quite a bit faster than the initial config write-up.  Finally I'll work on creating masks for the parts that currently lack them, and redoing/updating masks for a few parts that I think could be done differently;  this will be a very time-consuming step, with each new mask taking ~1 hour to make (more or less, depending upon complexity and messiness of the original texture and UV maps).

For the longest time I was resistant to making/publishing any config sets myself, but after the ongoing repeated requests for recoloring configs, and knowing the struggles others have endured trying to write them up and get them working, I decided it was time to just put something together.  That, and I was so sick of using stock parts alongside SSTU and having them look terribly out of place due to difference in coloring or shaders.  If/when it is released it will be as an optional/secondary download.

On the subject of releases -- I'll likely make the first releases available after I complete the normalization data pass on the configs.  At that point the existing configs should be usable and functional, and can work on adding the rest of the missing parts (new masks) in future releases.  Until then the repository is public if anyone is inclined to check it out ( https://github.com/shadowmage45/STUCK ), just note that I will likely not respond to any bug reports/issue tickets until after the first release.

 

Only have a couple of images at the moment as this project is still very much WIP:

Preview of the AERO parts, showing mask colors on all parts.

 

Recolored stock fins to match one of my SSTU rocket paint schemes:

 

And in further general development news:

I have noted a few bugs that have crept into TU in the past few releases that I'll be fixing up shortly.  Also may be adding some additional controls to the recoloring functions in the shader to allow for specifying the detail extraction and application method (add/mult, raw/proportional).  Might also be adding an additional control the recoloring-UI as a user-controlled 'detail multiplier'.  We'll see.

[Manwith Noname]

48 minutes ago, Shadowmage said:

...which I believe have evolved from KerbPaint originally...

A word on that.

Yes, they were originally made for KerbPaint. I'm 99% sure that none of the original masks that came with KerbPaint remain. The only parts I can think of that were perhaps not altered much are the early "aero fins". Anything post Porkjet is new and created by myself. Some of them still need some touch ups as the conversion from KerbPaint masks to TU left some of the original design with rounded corners due to the method I grabbed "layers".

If I'd known you were going to do this, I would have uploaded my latest version which includes masks for some of the "new" stock parts and config revisions which use mesh whitelisting exclusively. I had not dropped it entirely, I just got tired of doing things repeatedly due to changes in the game and TU. It was something I was going to pick up again when everything was "stable".

57 minutes ago, Shadowmage said:

I have noted a few bugs that have crept into TU in the past few releases that I'll be fixing up shortly.

Just in case it's not something you've noticed, I've had weird "sticking" of settings or textures when switching between texturesets. Looks like the metal and spec layers / channels get reversed. Also had issues with getting the GUI button to appear when using partvariants.

[Shadowmage]

8 minutes ago, Manwith Noname said:

A word on that.

Yes, they were originally made for KerbPaint. I'm 99% sure that none of the original masks that came with KerbPaint remain. The only parts I can think of that were perhaps not altered much are the early "aero fins". Anything post Porkjet is new and created by myself. Some of them still need some touch ups as the conversion from KerbPaint masks to TU left some of the original design with rounded corners due to the method I grabbed "layers".

Good to know.  I'll be adding proper attribution for all of the mask files that I'm re-using, so good to know where they came from and whom to give credit

9 minutes ago, Manwith Noname said:

If I'd known you were going to do this, I would have uploaded my latest version which includes masks for some of the "new" stock parts and config revisions which use mesh whitelisting exclusively. I had not dropped it entirely, I just got tired of doing things repeatedly due to changes in the game and TU. It was something I was going to pick up again when everything was "stable".

Understood, and no worries.  I think the process that I'm going through now is exactly what will be needed to get things to a 'stable' state (as far as use for patching existing parts is concerned).  Was hard for me to know what needed to be fixed/changed/adjusted without going through the process to actually use it myself (obv. it worked for what was needed in SSTU; but that is a bit of a special case, being authored for recoloring from the start, and integrated closely at the plugin level).  Up until now I've only toyed with the concept in limited fashion, only targeting a few specific parts with very basic configs.

Now that I've spent a fair bit of time writing recoloring patches, I have a much better grasp regarding what is functional, what is broken, what is a pain to deal with, and the other concerns specific to patching of existing parts.  Overall the process went about like I would expect for writing up the configs though.  A bit time consuming and very repetitive; some definite head-scratching moments trying to figure out some of the more odd edge-cases and seldom used features, but the core of the process seems to work exactly as it should when used as intended.

If you still have those new masks around, and don't mind sharing them, I'd certainly be willing to write up configs for those as well.  The more coverage the better

 

17 minutes ago, Manwith Noname said:

Just in case it's not something you've noticed, I've had weird "sticking" of settings or textures when switching between texturesets. Looks like the metal and spec layers / channels get reversed. Also had issues with getting the GUI button to appear when using partvariants.

Thanks for the info; I'll add those to the list of things to investigate (if you have specific examples/steps for reproduction it might help). 

I've definitely noticed some issues with texture sets affecting multiple parts in the editor(children parts), and a few instances of shader parameters sticking between changing of sets.  Haven't noticed anything with layer swapping (example?), nor have I run into any new issues with the TUPartVariant module, but I haven't toyed with it much (again, specific examples to reproduce could be helpful).

In the end I'm not meaning to usurp or replace the work you've done with Textures Unlimited Recoloring Depot, only looking to provide a known set of functional patches to use for examples for others to derive their own work from, and in the process sort through some of the usability issues and finish development of my external toolset (the one that calculates normalization parameters for you).  Still undecided if I want to actually release it, or just leave it as an online/hosted example set/personal project.

If you wanted to use any of the configs that I've written, feel free to grab them.  They have been written entirely from scratch, in a 'one-config-file-per-part' setup, so should be easy to pick apart specific bits if needed.  Or if there was any other level of collaboration desired please let me know -- I'm open to options.  Apologies on that, as I probably should have contacted you first regarding collaboration before posting anything on the project.  Certainly not too late to set something up though if desired

[Manwith Noname]

1 hour ago, Shadowmage said:

Thanks for the info; I'll add those to the list of things to investigate (if you have specific examples/steps for reproduction it might help).

It goes something like this...

I have a "metal set" using TU/Metallic and a "recolour set" using TU/Metallic with the recolour flag. I also have a "stock set" which defines the parts using stock shaders. I imagine you are familiar with this to some extent having started picking it all apart. So, you place a part in the editor and it is displayed as it would be in the stock game. Clicking "right" moves it to the metal texture set, clicking right again moves it to the recolour set.

Now, if I place a part and click "left" to go straight to the recolour set, it all works as I have defined it and as I would expect. If I move to the recolour set from the metal set, it's all a bit wrong and it appears as though the values are being applied in reverse with regard to the metal and specular parameters or texture values.

I'll pack up what I have and send it via PM. Place a standard MK2 cockpit and play around and presumably you'll see what I mean. Also, if I've been on the recolour setting and altered the colour of the part, when I switch to the metal set, the colour sticks.

[Manwith Noname]

Ok, I just checked my logs and I can see what is happening to some extent...

[LOG 20:32:23.256] Updated material properties
   Material Data : MK2Cockpit (Instance) (Instance)
       shader  : KSP/Emissive/Bumped Specular
       renderQ : 2000
       _MainTex : Squad/Parts/Command/mk2CockpitStandard/Cockpit (UnityEngine.Texture2D)
       _BumpMap : Squad/Parts/Command/mk2CockpitStandard/Cockpit_NRM (UnityEngine.Texture2D)
       _Emissive : Squad/Parts/Command/mk2CockpitStandard/Cockpit_Lum (UnityEngine.Texture2D)
       _Shininess : 0.4406686
       _Color : (1.0, 1.0, 1.0, 1.0)
       _EmissiveColor : (0.0, 0.0, 0.0, 1.0)

[LOG 20:32:26.313] Updated material properties
   Material Data : MK2Cockpit (Instance) (Instance)
       shader  : TU/Metallic
       renderQ : 2000
       _MainTex : Squad/Parts/Command/mk2CockpitStandard/Cockpit (UnityEngine.Texture2D)
       _BumpMap : Squad/Parts/Command/mk2CockpitStandard/Cockpit_NRM (UnityEngine.Texture2D)
       _MetallicGlossMap : TURD/TU_Stock_Recolour/Command/MK2 Cockpit Standard/170_mk2Cockpit_Standard_Spec (UnityEngine.Texture2D)
       _Emissive : Squad/Parts/Command/mk2CockpitStandard/Cockpit_Lum (UnityEngine.Texture2D)
       _AOMap : TURD/TU_Standardised_Switching/000_PlaceholderTextures/Occ (UnityEngine.Texture2D)
       _MaskTex : TURD/TU_Stock_Recolour/Command/MK2 Cockpit Standard/131_mk2Cockpit_Standard_Paint (UnityEngine.Texture2D)
       _Thickness : 
       _Smoothness : 1
       _Metal : 1
       _Color : (1.0, 1.0, 1.0, 1.0)
       _EmissiveColor : (0.0, 0.0, 0.0, 1.0)
       _MaskColor1 : (1.0, 1.0, 1.0, 1.0)
       _MaskColor2 : (1.0, 1.0, 1.0, 1.0)
       _MaskColor3 : (1.0, 1.0, 1.0, 1.0)
       _MaskMetallic : (0.0, 0.0, 0.0, 0.0)
       _DiffuseNorm : (0.8, 0.8, 0.8, 0.0)
       _SmoothnessNorm : (0.7, 0.7, 0.7, 0.0)
       _MetalNorm : (0.2, 0.2, 0.2, 0.0)
       TU_RECOLOR : True

[LOG 20:32:26.314] Updated material properties
   Material Data : MK2Cockpit (Instance) (Instance)
       shader  : TU/Metallic
       renderQ : 2000
       _MainTex : Squad/Parts/Command/mk2CockpitStandard/Cockpit (UnityEngine.Texture2D)
       _BumpMap : Squad/Parts/Command/mk2CockpitStandard/Cockpit_NRM (UnityEngine.Texture2D)
       _MetallicGlossMap : TURD/TU_Stock_Recolour/Command/MK2 Cockpit Standard/170_mk2Cockpit_Standard_Spec (UnityEngine.Texture2D)
       _Emissive : Squad/Parts/Command/mk2CockpitStandard/Cockpit_Lum (UnityEngine.Texture2D)
       _AOMap : TURD/TU_Standardised_Switching/000_PlaceholderTextures/Occ (UnityEngine.Texture2D)
       _MaskTex : TURD/TU_Stock_Recolour/Command/MK2 Cockpit Standard/131_mk2Cockpit_Standard_Paint (UnityEngine.Texture2D)
       _Thickness : 
       _Smoothness : 1
       _Metal : 1
       _Color : (1.0, 1.0, 1.0, 1.0)
       _EmissiveColor : (0.0, 0.0, 0.0, 1.0)
       _MaskColor1 : (1.0, 1.0, 1.0, 0.0)
       _MaskColor2 : (1.0, 1.0, 1.0, 0.0)
       _MaskColor3 : (1.0, 1.0, 1.0, 0.0)
       _MaskMetallic : (0.0, 0.0, 0.0, 0.0)
       _DiffuseNorm : (0.8, 0.8, 0.8, 0.0)
       _SmoothnessNorm : (0.7, 0.7, 0.7, 0.0)
       _MetalNorm : (0.2, 0.2, 0.2, 0.0)
       TU_RECOLOR : True

[LOG 20:32:33.745] Updated material properties
   Material Data : MK2Cockpit (Instance) (Instance)
       shader  : TU/Metallic
       renderQ : 2000
       _MainTex : Squad/Parts/Command/mk2CockpitStandard/Cockpit (UnityEngine.Texture2D)
       _BumpMap : Squad/Parts/Command/mk2CockpitStandard/Cockpit_NRM (UnityEngine.Texture2D)
       _MetallicGlossMap : TURD/TU_Standardised_Switching/000_PlaceholderTextures/Occ (UnityEngine.Texture2D)
       _Emissive : Squad/Parts/Command/mk2CockpitStandard/Cockpit_Lum (UnityEngine.Texture2D)
       _AOMap : TURD/TU_Standardised_Switching/000_PlaceholderTextures/Occ (UnityEngine.Texture2D)
       _MaskTex : TURD/TU_Stock_Recolour/Command/MK2 Cockpit Standard/131_mk2Cockpit_Standard_Paint (UnityEngine.Texture2D)
       _Thickness : 
       _Smoothness : 0.6
       _Metal : 0.8
       _Color : (1.2, 1.2, 1.2, 0.0)
       _EmissiveColor : (0.0, 0.0, 0.0, 1.0)
       _MaskColor1 : (1.0, 0.0, 0.0, 0.0)
       _MaskColor2 : (1.0, 1.0, 1.0, 0.0)
       _MaskColor3 : (1.0, 1.0, 1.0, 0.0)
       _MaskMetallic : (0.0, 0.0, 0.0, 0.0)
       _DiffuseNorm : (0.8, 0.8, 0.8, 0.0)
       _SmoothnessNorm : (0.7, 0.7, 0.7, 0.0)
       _MetalNorm : (0.2, 0.2, 0.2, 0.0)
       TU_RECOLOR : True

[LOG 20:32:33.745] ERROR: Could not locate recolorable section for part: mk2Cockpit.Standard (Part)
[LOG 20:32:33.745] Updated material properties
   Material Data : MK2Cockpit (Instance) (Instance)
       shader  : TU/Metallic
       renderQ : 2000
       _MainTex : Squad/Parts/Command/mk2CockpitStandard/Cockpit (UnityEngine.Texture2D)
       _BumpMap : Squad/Parts/Command/mk2CockpitStandard/Cockpit_NRM (UnityEngine.Texture2D)
       _MetallicGlossMap : TURD/TU_Standardised_Switching/000_PlaceholderTextures/Occ (UnityEngine.Texture2D)
       _Emissive : Squad/Parts/Command/mk2CockpitStandard/Cockpit_Lum (UnityEngine.Texture2D)
       _AOMap : TURD/TU_Standardised_Switching/000_PlaceholderTextures/Occ (UnityEngine.Texture2D)
       _MaskTex : TURD/TU_Stock_Recolour/Command/MK2 Cockpit Standard/131_mk2Cockpit_Standard_Paint (UnityEngine.Texture2D)
       _Thickness : 
       _Smoothness : 0.6
       _Metal : 0.8
       _Color : (1.2, 1.2, 1.2, 0.0)
       _EmissiveColor : (0.0, 0.0, 0.0, 1.0)
       _MaskColor1 : (1.0, 0.0, 0.0, 0.0)
       _MaskColor2 : (1.0, 1.0, 1.0, 0.0)
       _MaskColor3 : (1.0, 1.0, 1.0, 0.0)
       _MaskMetallic : (0.0, 0.0, 0.0, 0.0)
       _DiffuseNorm : (0.8, 0.8, 0.8, 0.0)
       _SmoothnessNorm : (0.7, 0.7, 0.7, 0.0)
       _MetalNorm : (0.2, 0.2, 0.2, 0.0)
       TU_RECOLOR : True

[LOG 20:32:33.745] ERROR: Could not locate recolorable section for part: mk2Cockpit.Standard (Part)

Process as outlined previously, place part, switch to recolour set, change colour, switch to metal set, switch back to recolour set. Not entirely sure when these entries are being generated during that but it certainly seems values and defined textures are sticking. It's odd though, metalglossmap changes when switching to metal from colour but the other way round.

[Shadowmage]

19 minutes ago, Manwith Noname said:

Not entirely sure when these entries are being generated during that but it certainly seems values and defined textures are sticking.

I believe that was by design/by request.  Someone had requested that I retain existing materials and their parameters, so that they could write shorter patches/configs (e.g. so they wouldn't have to re-specify the current settings or re-specify the same texture across multiple texture sets / so they only had to specify the details that were being changed);  which brings us to the current state-of-affairs.  I also believe there is a way to tell it to 'don't re-use the existing material, create an entirely new one', but don't remember the method off the top of my head.

I'm beginning to believe implement such a change was in error, and that I should have stuck with the default implementation of 'use a new material unless explicitly stated to re-use existing'.  Seems that would solve these little oddities quite nicely, and fits more with the intended method of writing configs and patching things.

 

Either way, thanks for the added information -- kind of confirms a suspicion I was having about what is going on.  I'll let you know what the outcome of the investigation is   (likely outcome is that I change some of the default behavior in the mod back to what it was/should have been the entire time)

[Manwith Noname]

@Shadowmage

That's why I always specifically define each texture for the appropriate set and added tiny place holders to stop "bleeding" of recolour sets in to plain metal but, here's where it gets interesting. I added _color, _metal and _smoothness parameters to the recolour set with basically 1.0 values everywhere and it all works. Textures change as they are supposed to, can switch back and forth. Not really sure where this crept in but it didn't really cross my mind to try this as those parameters were not specified as part of the recolour shader when I last looked at the source and I've had this setup going for a year and a half before I encountered this problem. At the time I just decided to wait it out and see what became of things with future changes.

 

Edit: Recolour = True still persists but I imagine setting recolour = false in the metal set will solve that.

 

Another edit: Oof, it's not a true or false flag in config setup.

Edited July 22, 2019 by Manwith Noname
More info

[Shadowmage]

1 minute ago, Manwith Noname said:

@Shadowmage

That's why I always specifically define each texture for the appropriate set and added tiny place holders to stop "bleeding" of recolour sets in to plain metal but, here's where it gets interesting. I added _color, _metal and _smoothness parameters to the recolour set with basically 1.0 values everywhere and it all works. Textures change as they are supposed to, can switch back and forth. Not really sure where this crept in but it didn't really cross my mind to try this as those parameters were not specified as part of the recolour shader when I last looked at the source and I've had this setup going for a year and a half before I encountered this problem. At the time I just decided to wait it out and see what became of things with future changes.

Yeah, I think it was part of an unfortunate batch of changes I made when I was last actively working on the mod.  Lets just say I have since learned to not make changes just to appease others, unless those changes are also personally desired.

 

2 minutes ago, Manwith Noname said:

That's why I always specifically define each texture for the appropriate set

Yeah, as long as you are fully defining your texture sets there really shouldn't be an issue (anything not defined should use the default value from the shader; not carry across some random, arbitrary, and unknown previous value).  The fact that it is currently not working with that setup (or at least, has some issues) would lead me to believe that I need to fix the mod itself

 

Pretty sure I'll have this cleaned up / fixed up for the next release   (which will hopefully be this weekend, time permitting).

[Shadowmage]

@Manwith Noname

I've tracked this down as to what is causing it.  Details can be found here:  https://github.com/shadowmage45/TexturesUnlimited/issues/72

You can try adding to the MATERIAL blocks a new line that states 'mode = create' to verify if that is the cause (and solution).  I'll be doing some verification of this myself as well.

I'll be updating TU to change the default mode to 'create' in the near future, as that is the intended default use of the mod and how I desire to write configs.  The other option is 'mode = update', which does the current behavior and updates the in-place texture set; useful for MODEL_SHADER, but plays havok with runtime texture switching as you and I have seen; it might also have some use with the part-variant system to adjust existing variants (but the preferred method would be to redefine them entirely through TU).

[Shadowmage]

Heads up -- new feature incoming:

User controllable 'Detail Multiplier' in the recoloring GUI.  Now you can select how much of the original textures extracted detail you want, including 'crank it up to 11'.

 

In the following images, the top is the recolorable version, bottom is stock pure textures for comparison.

No detail:

Std detail:

Doom-and-gloom over-multiplied detail (beyond 100% is usable; this is at like 400%):

Note that I've carefully tuned these masks and normalization parameters for these parts, and as with all other aspects of the recoloring system, actual outcome for any given part depends entirely upon how detailed and accurate the configuration data is.

 

Really was the last little piece missing from the normalized recoloring system.  Apparently I'd done 90% of the work in the last set of shader updates, but for some reason I never wrote the code to hook it up to the GUI or persist the values (could have been manually patched through PROPERTY nodes though).

Should be fully compatible with existing configs and texture-sets.  The default value is '100% detail', which is the current default value.  Should not require any additions to texture-sets to use the feature.  Should continue to load existing craft using recoloring as well -- if the value is not found in the saved persistence data, it defaults to '100%'.

This new feature, and a slew of bugfixes, should be available sometime this weekend.  A few more issues to investigate, but should be a good (and long overdue) release.

 

Edit:  Playing around with recoloring and use of detail multipliers -- good stuff.  Still a few masks to create/update, and lots of normalization data to fill in, but I'm really liking the results once it is all configured.  Extremely consistent recoloring across stock parts that had widely different colors to begin with, without having to play around with any colors.  Just create one the desired color scheme on one part, use 'store pattern', and then 'load pattern' on the rest of the parts; normalization takes care of matching everything up wonderfully.

Edited July 25, 2019 by Shadowmage

[Shadowmage]

More playing around with recoloring / mask creation / normalization setup.  Fun stuff.

Managed to get quite a bit of 'detail' into the detail-section of the masks for these parts from the original texture, including the rubbed off/scratched/worn paint scheme.

 

 

[ISOREX_]

On 7/22/2019 at 6:36 PM, Shadowmage said:

Thanks for the confirmation.  Yeah, that looks like the same icon-shader issues that I thought I had cleaned up.

What happens is that screen coordinates are inverted in OpenGL, and the icon-shader relies on screen coordinates to set up some screen-space based clipping.  At various times KSP has passed in regular coordinates, or pre-inverted coordinates, so I've played a bit of whack-a-mole with trying to keep up with their 'fixes'.  To make things more complicated, KSP manipulates things in plugin code, but I have to somehow handle it all entirely on the internals of the shader-side of things.  Fun stuff

(wanted to open an issue on Github to track it, but apparently Github doesn't want to load the TU repo at the moment; I'll try and remember to open the ticket later).

Thank you for explaining it a bit more. Also those screenshots look amazing 

Keep up the great work!

[Shadowmage]

Did a thing last night, see if you can spot it in this GUI

 

At one point was an often requested feature, that I just now managed to find a clean way to hook it into the existing code and GUI.  Still a bit more functionality to decide in regards to 'what is the default palette for any given part/module/section'; but the feature is functional and will be available in the next release.  I'll be defining a couple of standard palettes, but other mods/patch sets are free to define their own or edit the existing ones.

As mentioned above the last missing functional bit is 'what palettes are available for any given part'.  Likely will tackle that bit for the next release, after some further thought and discussion.  Currently all defined palettes are visible for every part.

Further, there is a 'FULL' palette that will by default contain all defined preset colors, that will likely be linked to a config option in the in-game settings menu to force it to be available for all parts regardless of what their config defines.

 

Just one more bit of fun coming with the next release (later today maybe?).

[Gordon Dry]

Palette ...