[1.12.x] Textures Unlimited Recolour Depot

[Manwith Noname]

3 minutes ago, KSPFanatic102 said:

Thanks alot!!!

 

No problem. I guess the version of TU was outdated so syntax was an issue.

[KSPFanatic102]

Can you add support for 5m parts and Making History DLC parts?

[Gordon Dry]

I have a suspicion:

When using TU_Stock and TU_Extra together with TweakScale, this can happen:

[TweakScale Warning] Exception during stockTextureSwitch interactionSystem.NullReferenceException: Object reference not set to an instance of an object
  at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 
  at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.ScalePart (Boolean moveParts, Boolean absolute) [0x00000] in <filename unknown>:0 
TweakScale.Tools:LogWf(String, Object[])
TweakScale.TweakScale:ScalePart(Boolean, Boolean)
TweakScale.TweakScale:Setup()
TweakScale.TweakScale:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:LoadModule(ConfigNode, Int32&)
ShipConstruct:LoadShip(ConfigNode, UInt32, Boolean, String&)
ShipConstruct:LoadShip(ConfigNode, UInt32)
ShipConstruct:LoadShip(ConfigNode)
ShipConstruction:LoadShip(String)
FlightDriver:setStartupNewVessel()
FlightDriver:Start()

 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

The part in question is the stock NPV-06 Parachute which I scaled down ... and set to "All shiny".
(craft in  linked archive below)

Perhaps this is also triggered by the same reason, perhaps it's something totally different:
(I don't use RF or MFT actually)

[TweakScale Warning] Exception during MFT interactionSystem.NullReferenceException: Object reference not set to an instance of an object
  at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 
  at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.UpdateMftModule () [0x00000] in <filename unknown>:0 
TweakScale.Tools:LogWf(String, Object[])
TweakScale.TweakScale:UpdateMftModule()
TweakScale.TweakScale:CallUpdaters()
TweakScale.TweakScale:Setup()
TweakScale.TweakScale:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:LoadModule(ConfigNode, Int32&)
ShipConstruct:LoadShip(ConfigNode, UInt32, Boolean, String&)
ShipConstruct:LoadShip(ConfigNode, UInt32)
ShipConstruct:LoadShip(ConfigNode)
ShipConstruction:LoadShip(String)
FlightDriver:setStartupNewVessel()
FlightDriver:Start()

 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Full log and stuff:
https://www.dropbox.com/s/0i3o5k0qjvdfulf/2018-10-13_1 KSP.log and stuff.7z?dl=1

[Gordon Dry]

btw the Parachute part is solid black in flight scene after rescaling ...

[Manwith Noname]

1 hour ago, Gordon Dry said:

btw the Parachute part is solid black in flight scene after rescaling ...

Just the canopy or the shroud too? I know about the canopy turning black but I thought I commented the offending code out so it wouldn't be listed. I'll investigate. I did dump tweakscale in as a test for a previous issue report but the parts I checked seemed to be fine. Kinda tricky testing everything though so thanks for the report.

[Gordon Dry]

@Manwith Noname in daylight (no direct sunlight in this case) the whole part is really dark, in a dark environment there is no reflection of the skybox at all (red gas clouds) and so it's pitch black.

@Manwith Noname turned around, direct sunlight gets a reflection:

[Manwith Noname]

@Gordon Dry

Dude....I think you need some more mods. I didn't mention this before but...

2 hours ago, Gordon Dry said:

stock NPV-06 Parachute

 

That isn't a stock part. I notice you have real chute so I'll investigate with that but I'm sorry, I'm not downloading every single mod you have to check what they do. Also, if you have any other TU configs from elsewhere, I would advise removing them as a test.

Edited October 13, 2018 by Manwith Noname

[Gordon Dry]

2 minutes ago, Manwith Noname said:

That isn't a stock part

Oh, sorry, I just have seen this in the MM cache and then assumed it:

UrlConfig
{
	name = parachuteSingle
	type = PART
	parentUrl = Squad/Parts/Utility/parachuteMk1/parachuteMk1
	PART
	{

...

 

Should have read that further ...

[Manwith Noname]

@Gordon Dry

I've installed tweakscale and realchute and the parachutes appear to be working fine for me...

Spoiler

As I said previously, my first step from here would be to remove any other TU patches you have installed and test without them.

 

Edit:

@Gordon Dry OK, I think I know what the problem is so I'm going to ping @Shadowmage. I suspect you are using quite a high level of ambient light boost and the shaders in TU (at least the metallic one anyway) don't appear to respond to it. There's nothing I can do about that. I'm also not sure that the "stockTextureSwitch" error is TU related but perhaps something to do with variants?

Edited October 13, 2018 by Manwith Noname

[Gordon Dry]

@Manwith Noname perhaps it's just conflicting with "Vandest Shiny Stock Parts" so I remove that config folder and see then ...

[Manwith Noname]

@Gordon Dry I'm 99.999999% sure what you have shown in your screenshots is related to the ambient light boost in the game settings. I noticed the difference in light levels between our pics and tested it before I edited my post. I stuck a craft in orbit so it was in the shadow of Kerbin and altered the setting. Anything with the stock shader got brighter but the parachutes which still had the metallic shader applied stayed dark.

If as I asked earlier the canopy of the parachute is black even in sunlight when popped, that could well be another config. That config just needs to exclude the canopy mesh (or perhaps rather target the other meshes except the canopy) and it will revert to stock and appear how it should.

[bvsveera]

On 10/13/2018 at 12:51 AM, Manwith Noname said:

@bvsveera

Ok, here's a quick fix which should hopefully allow you to use VSR parts without texture switching alongside the Stock parts which remain untouched by VSR with texture switching and recolour.

Not fully tested so there's a possibility it doesn't catch everything. I found a patch in the VSR pack which appears to target everything Ven and modified it.

 

Edit: Err..nope it doesn't work as I expected. It removes texture switching from everything it seems so ignore this. I knew it was too good to be true....

 

Another edit: Right...here we go...quick fix...

@PART[*]:HAS[#author[*Ven*]&@MODEL:HAS[#model[VenStockRevamp/*]]]:FOR[zzzzVSRPathPatch_1]
{
	!MODULE[KSPTextureSwitch],* {}
	!MODULE[SSTURecolorGUI]
}

Again, may not catch all but the things I checked worked out. @bvsveera Just tagging again if you already read this post....not even sure if tagging in edits works.

Tried the fix just now. Doesn't seem to be working 100% for me. For example, the Probodobodyne HECS2, a bunch of the fuel tanks and engines are still displaying the wrong texture, to name a few.

 

Now, that might be because I'm using a different version of VSR to you (I think I'm still on the old "official" one released way back in 1.2.x). Could you point me towards the version of VSR you're using? I'll upgrade to that and see if it works.

 

Also, just making sure I'm doing this correctly: the patch is to be saved as a .cfg and dropped into the GameData folder, right?

Edited October 15, 2018 by bvsveera
Accidental copy/paste of entire message

[Manwith Noname]

@bvsveera

Alright, turns out not all part patches change the author to Ven. I didn't fully test it (clearly), just made it quick and checked some parts, then removed it. This "should" grab anything that has a model from Ven...

@PART[*]:HAS[@MODEL:HAS[#model[VenStockRevamp/*]]]:FOR[zzzzVSRPathPatch_1]
{
	!MODULE[KSPTextureSwitch],* {}
	!MODULE[SSTURecolorGUI],* {}
}

Also, you are correct, just paste it into a cfg file anywhere inside GameData. I'll just say though, remember where it is because you might want to remove it some time in the future 

Edited October 15, 2018 by Manwith Noname

[bvsveera]

Quote

@PART[*]:HAS[@MODEL:HAS[#model[VenStockRevamp/*]]]:FOR[zzzzVSRPathPatch_1]
{
	!MODULE[KSPTextureSwitch],* {}
	!MODULE[SSTURecolorGUI],* {}
}

This works! Now all of Ven's "stock" parts look just like they should.

 

Quote

 remember where it is because you might want to remove it some time in the future 

Don't get my hopes up! 

[Manwith Noname]

Progress report....The (not so) leaning tower of Kerbal...

[Electrocutor]

1 hour ago, Manwith Noname said:

Progress report....The (not so) leaning tower of Kerbal...

 

Have you figured out how to use recoloring on all the different stock variant patterns? If not, I can help you out: I'm good with .cfg, but terrible with texture painting.

[Shadowmage]

On 10/13/2018 at 3:07 PM, Manwith Noname said:

I suspect you are using quite a high level of ambient light boost and the shaders in TU (at least the metallic one anyway) don't appear to respond to it.

Good news is that this should no longer be an issue with the 1.5 versions of TU shaders -- they will support the stock ambient light boost (as soon as I get over the absurdity of it, and implement it), as well as the stock underwater fogging effects.

9 hours ago, Manwith Noname said:

Progress report....The (not so) leaning tower of Kerbal...

The new 'normalization' feature of recoloring in the new shaders I think will be of great use to you.  Will likely be sending out some PM's this evening/over the weekend to discuss it and make sure you know how to use it -- even without any additional textures it still offers far better recoloring than the tinting mode.  Want to get the basic documentation written up first so I have some resources to use while trying to explain things

(of course, the old tinting mode will still be available, so none of the old configs should break; but I would highly recommend any new configs be done with the new shader/features)

[Manwith Noname]

On 10/19/2018 at 12:12 PM, Electrocutor said:

Have you figured out how to use recoloring on all the different stock variant patterns? If not, I can help you out: I'm good with .cfg, but terrible with texture painting.

Only in so far as I remove the Stock system and replace it with the TU slider for textures. That's what you see in the pic, each "variant" becomes a texture set. The only snag with this is model switching and the issue with converting the configs to nest TU settings in variants is you can't recolour from the GUI. Here's what hilarity ensues when you remove stock variants from the new rovemate...

Spoiler

Mmmmm, zfighting.

 

20 hours ago, Shadowmage said:

(of course, the old tinting mode will still be available, so none of the old configs should break; but I would highly recommend any new configs be done with the new shader/features)

I downloaded the dev build yesterday and have been playing around. The first thing I note is there appears to be some sort of issue where mask "layers" meet. If you've only checked this out on parts like the MK2 cockpit it would be easy to miss since all "layer borders" are in between the parts "panels" of the main texture (dark bits).

Spoiler

This is using the TU/Metallic shader without normalisation right now.

[Shadowmage]

2 hours ago, Manwith Noname said:

Here's what hilarity ensues when you remove stock variants from the new rovemate...

Yeah, for some silly reason they are using two different models, with different UV maps, in that variant setup.  I looked at it as well during attempts to set up a patch, but not sure of any good solutions.  I don't want to have TU get into model/mesh switching stuff as well...

 

2 hours ago, Manwith Noname said:

The first thing I note is there appears to be some sort of issue where mask "layers" meet.

I'm not sure what I'm supposed to be seeing in that image that would be incorrect... it all looks fine to me?

Edited October 20, 2018 by Shadowmage

[Manwith Noname]

19 hours ago, Shadowmage said:

I don't want to have TU get into model/mesh switching stuff as well...

I can understand that. If there was a way of hooking in so that a texture set could specify the "GAMEOBJECTS" it would be handy though.

 

19 hours ago, Shadowmage said:

I'm not sure what I'm supposed to be seeing in that image that would be incorrect... it all looks fine to me?

This will hopefully visualise what I'm explaining very badly...

Spoiler

It could just be some weirdness with how I have everything setup but essentially, all inputs are the same for both shaders. The left is TU/Metallic, the right is SSTU/PBR/Masked.

 

Edit: Huh...so this is the TU/Metallic shader on the SRBs. Both are recoloured but one is just my usual RGB scheme to visualise things and the other I altered the colours to look like the stock part. Note, it's not using the striped texture, the diffuse is all "white".

Spoiler

Reminds me of the old saying, red and green should not be seen without a colour in between.

Another edit:...and I'm going to improve the "wear and tear" so it doesn't look like someone blobbed a round pencil at the edges....

Edited October 21, 2018 by Manwith Noname

[Electrocutor]

@Shadowmage @Manwith Noname

So, the main issue stems from the recolor button not showing up unless you use the TU Part Module; otherwise, you could have TU hook onto the variant changed event and look through the KSP_MODEL_SHADER configs for any matching model names after the variant has switched the model. Another trick could be to allow 3rd part shader setting under the EXTRA_INFO, like the fairing PartModule does: the EXTRA_INFO cfg node is delivered as a parameter to the PartVariant event.

So basically, you can create a different RecolorMap to match each of the stock PartVariants, and set it via the PartVariant cfg using ModuleManager; The only TU stuff that can't be set by PartVariants is the shader (which can be done via KSP_MODEL_SHADER) and enabling keywords: both of which _could_ be setup to check for inside the EXTRA_INFO cfg section of the variant. For example, you could add a TU_CONFIG {} node with shader= and keyword= values.

MODULE {
	name = ModulePartVariants

	VARIANT {
		TEXTURE {
			_MaskTex = TURD/Parts/Something/something_mask
			// PartVariants parse by materialName, but it doesn't hurt to have extra textures set that aren't used if a 
			// single materialName covers multiple meshes that are or not included in the TU cfg section
		}
		EXTRA_INFO {
			TU_CONFIG {
				shader = SSTU/PBR/Masked
				keyword = TINT
				keyword = GLOSS_DIFF_ALPHA

				mesh = abc
				excludeMesh = def
			}
		}
	}
}

 

[Shadowmage]

6 hours ago, Manwith Noname said:

This will hopefully visualise what I'm explaining very badly...

  Hide contents

Thanks for the comparison.  Yes, I can see the differences there (I thought that black edge was intentional, having not seen the comparison) -- I would say to compare again once you have normalization set up (the new shader, in its current state, really needs that data to function properly), but there could also be an issue with how I'm blending the colors on the edges.  I would guess what is happening is that your masks aren't 100% on those pixels, so it is pulling through some of the base texture, and as it is not 'normalized' it ends up being extremely dark.

(the current shader has a 'bug' where if you don't supply normalization in the mask.alpha channel, it interprets it as '1.0' for all pixels, and so subtracts that from the diffuse -- this is due to the inability to specify a default alpha value in texture samplers for when the input texture does not contain alpha -- I need the default value to be '0', but Unity passes '1')

I will look into it today though, and let you know what I find out.  Is that MASK texture available in the current releases?

6 hours ago, Manwith Noname said:

Edit: Huh...so this is the TU/Metallic shader on the SRBs. Both are recoloured but one is just my usual RGB scheme to visualise things and the other I altered the colours to look like the stock part. Note, it's not using the striped texture, the diffuse is all "white".

Is that mask in the current pack as well?  The more samples I have for testing, the better

Could also be that your masks themselves aren't 'normalized' (in the unit-vector sense).  Do the R+G values in those pixels add up to '255' ?  The only time the mask R+G+B should sum to <255i/1.0f is if you want the original texture to show through;  they should never sum >255i/1.0f, or you will have rendering artifacts.  --- Hmm... might be some opportunity for a 'mask normalization' tool that you can run on your mask textures to make sure they are conformant....

 

 

 

 

50 minutes ago, Electrocutor said:

So, the main issue stems from the recolor button not showing up unless you use the TU Part Module

Don't think that is solveable.  Only way to add buttons to the GUI is with part-modules.  But... I'm also not seeing the issue?  Should be fine to add the recoloring button even if the part uses the stock variant system (aside from the current incompatibilities).  The recoloring button doesn't require any texture-switch modules as far as I know, and should work fine on its own (erm... perhaps I did change this recently to interact with texture-sets/texture switch....if so, could add a config-level toggle to disable that requirement).

51 minutes ago, Electrocutor said:

Another trick could be to allow 3rd part shader setting under the EXTRA_INFO, like the fairing PartModule does: the EXTRA_INFO cfg node is delivered as a parameter to the PartVariant event.

Interesting -- that seems like it might be viable.  Let the stock system do its silly stuff (swapping model/meshes), and just have TU come in behind it to do cleanup.  As long as the stock system passes the texture-set info for the proper model/mesh in use, should all work out.  Don't even need to pass in the whole config, just the name of the texture set to use.  Does that even fire before, during, or after the stock code has finished doing its thing?

 

53 minutes ago, Electrocutor said:

So basically, you can create a different RecolorMap to match each of the stock PartVariants, and set it via the PartVariant cfg using ModuleManager; The only TU stuff that can't be set by PartVariants is the shader (which can be done via KSP_MODEL_SHADER) and enabling keywords: both of which _could_ be setup to check for inside the EXTRA_INFO cfg section of the variant. For example, you could add a TU_CONFIG {} node with shader= and keyword= values.

I like it... seems workable.  Would at least allow for TU to be used alongside the stock part-variant system for compatibility with the existing stock parts that use it.  Still wouldn't let -me- use the stock part-variant system for anything.... but for that, major changes would have to be done to the stock system (e.g. multiple variant sets per part).

 

Will see what I can come up with on this end.  @Electrocutor has already worked through much of the logic on it, so would 'just' need to put it into code... and as its hooking into an existing event, shouldn't be too hard.  Likely won't have this for the initial 1.5 update, but should be able to come up with something within the next week or so.

[Shadowmage]

@Electrocutor @Manwith Noname

I've implemented stock-part-variant integration mostly as proposed above.  It is accomplished by leveraging the existing framework of code to handle texture swapping and recoloring;  the configs are a bit verbose, but functional.  One new module is added to the part that listens for the PartVariant events and reads the EXTRA_INFO from them and also implements the IRecolorable interface for interaction with the recoloring GUI.  The recoloring GUI module may also be added if recoloring is desired -- it will only show up if the currently selected variant (and its assigned texture set) supports recoloring.   

Basically it lets the stock variant system handle the UI and game-object/mesh stuff, but takes over the rest of the shader/material/property/texture handling through the existing KSP_TEXTURE_SET definitions/system.  You cannot have multiple texture sets per variant (if you want that... add more variants and point them to new texture sets);  but any given texture set should support any/all features that are available through the rest of TU's system (multiple material blocks / per-mesh assignment, custom recoloring values, etc).

A sample of the config syntax for the probe body (idk if the 'inherit' line is even the right name for it, so these configs can likely be improved):

@PART[roverBody_v2]
{
	@MODULE[ModulePartVariants]
	{
		@VARIANT[White]
		{		
			EXTRA_INFO
			{
				TU_TextureSet = StockRoverBody1
			}
		}
		@VARIANT[Silver]
		{		
			EXTRA_INFO
			{
				TU_TextureSet = StockRoverBody2
			}
		}
		@VARIANT[Gold]
		{		
			EXTRA_INFO
			{
				TU_TextureSet = StockRoverBody3
			}
		}
	}
	MODULE
	{
		name = TUPartVariant
		//you should assign this to the same texture set that will be used by the default part-variant
		//in this case that is the 'white' variant
		textureSet = StockRoverBody1
	}
	MODULE
	{
		name = SSTURecolorGUI
	}
}

KSP_TEXTURE_SET
{
	name = StockRoverBody1
	//model = Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2
	title = Default
	MATERIAL
	{
		shader = TU/Specular
		mesh = bodyWhite
		inherit = false
		texture = _MainTex, Squad/Parts/Command/probeCoreCube/QBE_New_diffuse
		texture = _BumpMap, Squad/Parts/Command/probeCoreCube/QBE_New_NRM
		keyword = TU_STOCK_SPEC
		float = _Smoothness, 0.55
	}
}
KSP_TEXTURE_SET
{
	name = StockRoverBody2
	//model = Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2
	title = Default
	MATERIAL
	{
		shader = TU/Specular
		mesh = bodyFoil
		inherit = false
		texture = _MainTex, Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_silver_diffuse
		texture = _SpecMap, Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_silver_specular
		texture = _BumpMap, Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_silver_NRM
		//keyword = TU_STOCK_SPEC
		float = _Smoothness, 0.55
	}
}
KSP_TEXTURE_SET
{
	name = StockRoverBody3
	//model = Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2
	title = Default
	MATERIAL
	{
		shader = TU/Specular
		mesh = bodyFoil
		inherit = false
		texture = _MainTex, Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_gold_diffuse
		texture = _SpecMap, Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_gold_specular
		texture = _BumpMap, Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2_gold_NRM
		//keyword = TU_STOCK_SPEC
		float = _Smoothness, 0.55
	}
}

 

Will be pushing this to the dev branch shortly (30m-1hr).  It is hot off the compiler though, and a very quick-and-dirty implementation, but should be functional enough to see if the concept will work out.

[KSPFanatic102]

will TURD work in 1.5.1 or is it still in progress

 

[Gordon Dry]

Is this a known issue?