[1.12.x] Textures Unlimited Recolour Depot

[Manwith Noname]

I've added a config set to the OP which implements the familiar "make it shiny" metallic setup and falls in line with the standardised switching. It's mainly so engines don't just sit on the stock shader. With a bit of find and replacing it can be used to make further patches for variations of a theme and more.

[Chimichanga]

Superb!  Oh, where has this mod been all my life?!

I'm sure it's on your radar, but about those Making History parts..... 

 

[Manwith Noname]

Heh, I did the same when workshop went live with someones SR-71 craft. As for Making History...one day, though a lot of the parts have stock variants system in place from memory and it doesn't play well with the custom recolour module right now. Basically, you'd be able to paint them in the VAB / SPH but it will revert to no paint when launched.

 

There's been a really small update to MK3 Expansion config and the stock recolour pack. Something slipped in the stock pack that I'd completely forgotten I had done. It was a quick test months ago and initially I was just going to remove it but instead I touched it up so it is more inline with what I had intended to do but never got round to. It also fixes a missing part of a colour map. MK3 "fix" was the "oh I forgot to do something" I mentioned previously.

If people notice things that seem wonky, please let me know. While I am aware quite a few colour maps still need polishing because converting them from KerbPaint to TU screwed with them a little, I might miss some issues since I don't currently play the game and only really look at parts as and when I'm editing them.

[Shadowmage]

5 hours ago, Manwith Noname said:

though a lot of the parts have stock variants system in place from memory and it doesn't play well with the custom recolour module right now

If you are 'updating' the parts to use TU -- you can remove all of that stock part-variant stuff and use TU's 'KSPTextureSwitch' part-module for texture switching (if even needed).  Its a bit more aggressive of a patch, but there really is no way to get both TU + the stock system to play nicely together (mostly because I cannot change the stock code, and it is written with so many assumptions on part/model/material/shader setup).

[Electrocutor]

Does it not work to have the RGB map texture as one of the variants, then also add part recoloring?

[Manwith Noname]

1 hour ago, Shadowmage said:

...you can remove all of that stock part-variant stuff and use TU's 'KSPTextureSwitch' part-module for texture switching (if even needed).  Its a bit more aggressive of a patch...

Yep, this is the road I started down back in April for the new jumbo fuel tanks. It hit a dead end there because the orange tanks .mu file seems to not have a collider mesh. I was basically going to set them up as separate parts but when doing so the orange tank could not be interacted with once it was placed. I could be wrong but I am assuming that it is the collider that KSP uses to determine if you have moused over a part. For stock parts that literally just change texture with variants it would be perfectly viable however.

 

Edit:

21 minutes ago, Electrocutor said:

Does it not work to have the RGB map texture as one of the variants, then also add part recoloring?

I did attempt to fudge something like this back then also. I got the shader to apply through variants with fixed colours and added an empty texture switch setup with recolour module. I didn't get it to work but that's not to say it isn't possible.

 

Another edit: Hmmm, I just had another look and Squad have changed how the Rockomax tanks are configured with variants somewhere between 1.4.1 and 1.4.5. Time to fiddle.

Edited September 26, 2018 by Manwith Noname

[Shadowmage]

10 minutes ago, Manwith Noname said:

It hit a dead end there because the orange tanks .mu file seems to not have a collider mesh.

Interesting... I haven't investigated the stock part-variant system much (undocumented, no source access), so I couldn't say for certain how they have those parts set up.  A brief look at the part configs would hint that they are using a single model, and selectively enabling/disabling specific meshes based on the variant (something not supported by TU) -- as the collider mesh is not listed in the variants, I would assume it is always part of the model.mu.  Perhaps that transform is 'disabled by default' in the model file, and only enabled specifically by the variant system at runtime?  Thus when you use the model 'normally' -- it lacks a collider?

Hmm.... yeah.... not sure TU could really support such a setup without branching out into some really ugly areas (model manipulation).  I didn't realize stock was doing silly things like that...

Will give it some thought though.  Might be able to come up with a solution specifically to allow for support of those parts... without branching into dynamic model manipulation. 

[Manwith Noname]

@Shadowmage Yeah, that's what I just found, they enable or disable the tube mesh from within a single model file. Back in 1.4.1, there were two distinct mu files for B&W and Orange.

[Shadowmage]

20 minutes ago, Manwith Noname said:

Back in 1.4.1, there were two distinct mu files for B&W and Orange.

Which is, IMO, the only proper way to do it.  Two separate models?  Put them in two separate files....

(sadly, even that would not help solve this problem;  stock was never supposed to have mesh-switching, as stated by previous devs multiple times, and thus I did not include any provisions for such features while developing TU)

[Manwith Noname]

11 minutes ago, Shadowmage said:

(sadly, even that would not help solve this problem...)

Kind of. If the Orange model was previously complete and functional as a separate model, then it would just sit as its own part in the menu and be configured like everything else.

I've just noticed something else though....have a look at the rockomax_16 [AlbedoM] BW.dds texture.  I.....I'm lost for words. 

[Shadowmage]

51 minutes ago, Manwith Noname said:

have a look at the rockomax_16 [AlbedoM] BW.dds texture.  I.....I'm lost for words. 

What about it?  Looks about like a standard texture file to me.  (genuinely curious what you spotted in there...)

[Manwith Noname]

27 minutes ago, Shadowmage said:

What about it?  Looks about like a standard texture file to me.  (genuinely curious what you spotted in there...)

The alpha channel is flipped, so part of the tube of the tank shines like an end cap and the "ridges" are out of place.

Edited September 26, 2018 by Manwith Noname

[Shadowmage]

5 minutes ago, Manwith Noname said:

The alpha channel (or maybe the main layer) is flipped, so part of the tube of the tank shines like an end cap and the "ridges" are out of place.

Yep, can confirm; didn't even look at the alpha before.  Specular layer is inverted in the texture compared to the diffuse, at least when I extract the channels using GIMP's Colors->Decompose tool.  Looks the same when I simply view the channels of the raw image though... so.... yeah.... quite the 'oops' you found there.

The real question is -- does the errant specular map show up like that in-game?    Yes... yes it does.  (note the non-shiny to shiny transition at the right side of the tank, near the end) (someone should report this to SQUAD so that they might fix it for the 1.5 release...)

 

[Electrocutor]

@Manwith Noname Suggestion: redefine the list of preset colors that comes with TU as they don't match the stock color scheme and most don't have any metal/smooth set on them. (you can use an MM patch to remove the existing ones)

... it also just occurred to me that your mod is listed as turd... I apologize, but I had to laugh several times.

 

@Shadowmage In order for the recolor GUI to make the surface 100% smooth, it requires 512 specular value; but the slider only goes to 255; why is this the case? His metal/gloss alpha values range between 20 and 75.

Edited September 27, 2018 by Electrocutor

[Manwith Noname]

53 minutes ago, Electrocutor said:

@Manwith Noname Suggestion: redefine the list of preset colors that comes with TU as they don't match the stock color scheme and most don't have any metal/smooth set on them. (you can use an MM patch to remove the existing ones)

This has popped in mind a couple of times. Not necessarily removing existing presets but adding some that are more inline with how things are configured currently, which is explained by...

 

53 minutes ago, Electrocutor said:

@Shadowmage In order for the recolor GUI to make the surface 100% smooth, it requires 512 specular value; but the slider only goes to 255; why is this the case? His metal/gloss alpha values range between 20 and 75.

This is because I'm currently cheating the system and using the existing stock textures for colour, specular and metallic scaling. The intention is to change this but as I've said a few times, while Squad are still changing textures and models, I'm not massively enthused by the prospect of spending the many hours creating maps that will become obsolete with the next patch.

So, stock "white" doesn't reach 255 in any of the RGB scales. This then also applies to specular. If the part texture has a solid white alpha you get metallic scaled correctly (without any "detail") but those which have specular maps result in the metal scale being off.

53 minutes ago, Electrocutor said:

...I apologize, but I had to laugh several times.

No need. To put this in to perspective, back in 2014 / 2015, I had intended to start something called, Kerbpaint Repository for Addons Project. It's just my warped sense of humour.

 

Edit: Oh additionally on the specular scale. White parts should only need somewhere in the 300 range to get full spec. Where the colouring is occurring over darker parts of the texture you'll need higher values.

Edited September 27, 2018 by Manwith Noname

[Electrocutor]

12 minutes ago, Manwith Noname said:

This is because I'm currently cheating the system and using the existing stock textures for colour, specular and metallic scaling. The intention is to change this but as I've said a few times, while Squad are still changing textures and models, I'm not massively enthused by the prospect of spending the many hours creating maps that will become obsolete with the next patch.

So, stock "white" doesn't reach 255 in any of the RGB scales. This then also applies to specular. If the part texture has a solid white alpha you get metallic scaled correctly (without any "detail") but those which have specular maps result in the metal scale being off.

The TINTING_MODE keyword will double the impact of the original RGBA from both the main texture and the glossmetal texture, though that would also negatively impact the selected color values form the GUI.

Edited September 27, 2018 by Electrocutor

[Manwith Noname]

I think it's the other way around. Tinting mode puts TU in to "subtraction". So it looks at the base texture and subtracts values from there. Without tinting mode, TU expects a grey 128 baseline and uses multiplication.

 

Edit: That's my over simplified attempt at describing it anyway. It's not as simple as just subtracting since you can still oversaturate.

Edited September 27, 2018 by Manwith Noname

[Shadowmage]

2 hours ago, Manwith Noname said:

Tinting mode puts TU in to "subtraction". So it looks at the base texture and subtracts values from there. Without tinting mode, TU expects a grey 128 baseline and uses multiplication.

Standard mode in masked areas (simplified a bit):

Output-RGB = TextureRGB - (127,127,127) + userMaskColorForSection  //(it actually adds all THREE user colors... but only one _should_ be used based on the color of the mask for that pixel)

 

Tinting Mode -- uses standard color multiplication (the same thing that happens when you use the _Color property):

Output-RGB = TextureRGB * userMaskColorForSection

 

Specular and metallic use the same maths as the diffuse RGB (either offset and add in standard mode, or multiply in tinting mode)

 

 

3 hours ago, Electrocutor said:

In order for the recolor GUI to make the surface 100% smooth, it requires 512 specular value; but the slider only goes to 255; why is this the case?

Because the system is being used incompletely.  Properly setup, using gray-based input textures, the range of 0-255 covers full standard (non HDR) color range.

[Electrocutor]

24 minutes ago, Shadowmage said:

Because the system is being used incompletely.  Properly setup, using gray-based input textures, the range of 0-255 covers full standard (non HDR) color range.

The smoothness has to get some value from the main texture alpha channel, some value from the recolor selection integer, and some value from the gloss/metal map red channel, right? Exactly how much are from which?

Edited September 27, 2018 by Electrocutor

[Manwith Noname]

20 minutes ago, Electrocutor said:

The smoothness has to get some value from the main texture alpha...

Not with the masked shader. The masked shader uses the _SpecMap for smooth and metal, like the PBR Metallic shader uses the _MetallicGlossMap, but the layers are flipped (Masked looks for smoothness on the main layer and metal in the alpha, Metallic shader is the other way around). The Stock Metallic Bumped shader looks at the _MainTex alpha for smoothness and at the gloss map main layer for metal.

Edited September 27, 2018 by Manwith Noname

[Electrocutor]

29 minutes ago, Manwith Noname said:

Not with the masked shader. The masked shader uses the _SpecMap for smooth and metal, like the PBR Metallic shader uses the _MetallicGlossMap, but the layers are flipped. The Stock Metallic Bumped shader looks at the _MainTex alpha for smoothness.

Not main texture, sorry; mask texture... here is the actual shader part for smooth and metal, but I'm not sure exactly how it acts.

fixed m = saturate(1 - (mask.r + mask.g + mask.b));
fixed3 userSpec = mask.r * _MaskColor1.a + mask.g * _MaskColor2.a + mask.b * _MaskColor3.a;
fixed userMetallic = mask.r * _MaskMetallic.r + mask.g * _MaskMetallic.g + mask.b * _MaskMetallic.b;

fixed3 baseSpec = spec.rgb * m;
fixed baseMetallic = spec.a * m;

fixed3 detailSpec = (spec.rgb - 0.5) * (1 - m);
fixed detailMetallic = (spec.a - 0.5) * (1 - m);

o.Smoothness = saturate(userSpec + baseSpec + detailSpec).r;
o.Metallic = saturate(userMetallic + baseMetallic + detailMetallic);

It only ever looks at the mask, the glossmap, and the user recolor.

Edited September 27, 2018 by Electrocutor

[Shadowmage]

2 hours ago, Electrocutor said:

Exactly how much are from which?

In tinting mode?  It loads the full value from the original texture, and then multiplies by the user selected color/spec/metal values multiplied by the inverse of the mask intensity (so black mask = no effect from user input).

In standard/non-tinting mode?  The contribution from the original texture is much harder to explain; simply use the gray base textures as intended and it will work (really, the explanation is in the shader source code below).

 

Here is the 'full' source of the PBR-Masked shader:

//these values are the values sampled from the textures
fixed4 color = tex2D(_MainTex,(IN.uv_MainTex));
fixed3 mask = tex2D(_MaskTex, (IN.uv_MainTex));
fixed4 spec = tex2D(_SpecMap, (IN.uv_MainTex));
fixed3 normal = UnpackNormal(tex2D(_BumpMap, IN.uv_MainTex));
fixed4 ao = tex2D(_AOMap, (IN.uv_MainTex));
fixed4 glow = tex2D(_Emissive, (IN.uv_MainTex));

// the variable 'm' controls how much of the base texture color is used, and how much comes from the user-selected color
// the brighter the colors in the mask, the more that the outputs are controlled by the user colors.  Duller (or black) mask, means the outputs are controlled only from the texture samples
fixed m = saturate(1 - (mask.r + mask.g + mask.b));
// this calculates the user-specified color for this pixel by some dirty shader-swizzled vector math
fixed3 userColor = mask.rrr * _MaskColor1.rgb + mask.ggg * _MaskColor2.rgb + mask.bbb * _MaskColor3.rgb;
// just like the line above, but for specular
fixed3 userSpec = mask.r * _MaskColor1.a + mask.g * _MaskColor2.a + mask.b * _MaskColor3.a;
// just like above, but for metallic
fixed userMetallic = mask.r * _MaskMetallic.r + mask.g * _MaskMetallic.g + mask.b * _MaskMetallic.b;
	
fixed3 diffuseColor = color.rgb * m;
fixed3 baseSpec = spec.rgb * m;
fixed baseMetallic = spec.a * m;
			
#if TINTING_MODE
	fixed3 detailColor = color.rgb * (1 - m);
	fixed3 detailSpec = spec.rgb * (1 - m);
	fixed detailMetallic = spec.a * (1 - m);
	o.Albedo = saturate(userColor * detailColor + diffuseColor);
	o.Smoothness = saturate(userSpec * detailSpec + baseSpec).r;
	o.Metallic = saturate(userMetallic * detailMetallic + baseMetallic);
#else
	fixed3 detailColor = (color.rgb - 0.5) * (1 - m);
	fixed3 detailSpec = (spec.rgb - 0.5) * (1 - m);
	fixed detailMetallic = (spec.a - 0.5) * (1 - m);
	o.Albedo = saturate(userColor + diffuseColor + detailColor);
	o.Smoothness = saturate(userSpec + baseSpec + detailSpec).r;
	o.Metallic = saturate(userMetallic + baseMetallic + detailMetallic);
#endif

o.Occlusion = ao.r;
o.Normal = normal;
o.Emission = glow.rgb * glow.aaa * _EmissiveColor.rgb *_EmissiveColor.aaa + stockEmit(IN.viewDir, normal, _RimColor, _RimFalloff, _TemperatureColor) * _Opacity;
o.Alpha = _Opacity;

 

Edit: Trying to think of a good way to explain the masked shaders 'standard' mode....

On non-masked pixels (mask texture is black) -- the original textures are used without change.

On masked pixels the standard diffuse/spec/metallic values for the pixel are used as a 'detail texture' applied on top of the user-selected color/spec/metal value.  In order to facilitate using the original texture detail for both highlights and shadows, the base value for that texture sample is offset by -0.5.  Thus a 1.0 (white) becomes a +0.5, and a 0.0 (black) becomes a -0.5; in this way the data from the original textures can both 'add' and 'subtract' from the user-selected color based on how far from neutral gray (0.5) that pixel is.

 

Edited September 27, 2018 by Shadowmage

[Electrocutor]

1 hour ago, Shadowmage said:

On non-masked pixels (mask texture is black) -- the original textures are used without change.

On masked pixels the standard diffuse/spec/metallic values for the pixel are used as a 'detail texture' applied on top of the user-selected color/spec/metal value.  In order to facilitate using the original texture detail for both highlights and shadows, the base value for that texture sample is offset by -0.5.  Thus a 1.0 (white) becomes a +0.5, and a 0.0 (black) becomes a -0.5; in this way the data from the original textures can both 'add' and 'subtract' from the user-selected color based on how far from neutral gray (0.5) that pixel is.

 

I'll use his mk2 inline as an example on the painted part. I'm ignoring the RGB component because that works just fine.

For specular:
diffuse.RGBA is ignored
mask.R is 255
mask.GBA is 0
spec.RGB is 192
spec.A is ignored
recolor.A is 255

so:
m = 1 - 1 - 0 - 0 = 0
user = 1 * 1 + 0 * 1 + 0 * 1 = 1
base = 0.75 * 0 = 0
detail = (0.75 - 0.5) * (1 - 0) = 0.25
smoothness = 1 + 0 + 0.25 = 1.25 = 1

except, it isn't 100%; instead it is somewhere around 50%

Edited September 27, 2018 by Electrocutor

[Manwith Noname]

Heh, I know this is about understanding the code and the math but here's how I see it....

The specmap ultimately defines the maximum possible value attainable. As you say, the red channel is 190 (0.75), so with the spec slider at 255 (1) in the GUI, the value I expect to be output for spec is 190 (0.75).

 

Edit:...and just from looking at things, that seems to align with what I see. I'd need to load it up to be perfectly sure but I seem to recall, like I said earlier, full gloss on "white" parts should happen between 300-350.

Edited September 27, 2018 by Manwith Noname

[Shadowmage]

54 minutes ago, Electrocutor said:

except, it isn't 100%; instead it is somewhere around 50%

I'm not seeing the problem?  The maximum deviation from gray will be +0.5 (white) or -0.5 (black), thus 50%.  Your main textures should never be very far from flat gray in portions that are masked for recoloring.

1 hour ago, Electrocutor said:

spec.RGB is 192

That is the problem.  Spec input should be 127 for any masked area on the texture.

An specular texture input of 192 is basically saying 'add 65 to whatever the user selected specular color is'.  (192 - 127 = 65).

An specular texture input of 100 is basically saying 'subtract 27 from whatever the user selected specular color is'  (100 - 127 = -27)