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

Shadowmage · February 13, 2018

10 hours ago, Barar said:

I am not a programmer but I think it might be hitting a max integer or something somewhere in Unity.

10 hours ago, Barar said:

5,254,535,100 - Crashing.

Hmm.. entirely possible. I would think that lists/etc should be stable up to ~2 billion entries, but perhaps they are using a different data type for the length, or it is otherwise bounded by some other constraint.

10 hours ago, Barar said:

Also is it possible to mod them to have a 10m, 20m+ height to them, so I could build some roaming bases construction tools, with maybe a faux land carrier not hugging the ground.

https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelRepulsor.cs#L33

But I make no guarantees about performance/stability when it is adjusted. Totally on your own if you change it from the default.

Shadowmage · March 10, 2018

Will have an updated TU release for KSP 1.4 sometime tomorrow. Likely will have a few changes in it that will require other mods to update their configs; will post more information with the release on what changed and how to best update the configs for the changes.

Shadowmage · March 11, 2018

Unfortunately there is a lot more that I need to do in order to pack + release TU than with my other mods, which I had... not taken into consideration when posting my intentions yesterday about doing a release today.

Not only do I need to update the actual plugin (the easy part, relatively), but I have to download, setup, and deal with a new Unity Editor version in order to be able to recompile the shaders (Unity shaders are editor/player version-locked). As such, it is going to be delayed until next weekend -- I simply don't have the time to deal with Unity shenanigans today or during the week.

This next/upcoming release will not be compatible with existing configs -- there have been some minor changes to the config layout/naming in order to make things a bit more 'clear' as to what each config node defines/adjusts. The overall structure and functions have not changed, just a few node names. At this point there have been no changes to the shaders, so the below config node names should be the extent of the 'breaking' changes.

Here is the list of changes, and in what order you should do the search/replace. I recommend using Notepad++ and its 'find and replace in all open documents' feature in order to fix all of your configs in a single pass.

1.) TEXTURE -> MATERIAL

2.) TEXTURESET -> KSP_TEXTURE_SET

So, for example the following (old) config:

@SSTU_MODEL[MFT-A-0-5|MFT-A-1-0|MFT-A-1-5|MFT-A-2-0|MFT-A-2-5|MFT-A-3-0|MFT-A-3-5|MFT-A-4-0|MFT-A-4-5|MFT-A-5-0|MFT-A-5-5|MFT-A-6-0|MFT-A-6-5|MFT-A-7-0|MFT-A-7-5|MFT-A-8-0|MFT-B-0-5|MFT-B-1-0|MFT-B-1-5|MFT-B-2-0|MFT-B-2-5|MFT-B-3-0|MFT-B-3-5|MFT-B-4-0|MFT-B-4-5|MFT-B-5-0|MFT-B-5-5|MFT-B-6-0|MFT-B-6-5|MFT-B-7-0|MFT-B-7-5|MFT-B-8-0]:FOR[SSTU]
{
	TEXTURESET
	{
		name = MFT-Stripes1-Stringers
		title = S1-S
        recolorable = true
		TEXTURE
		{
			shader = SSTU/Masked
			texture = _MainTex, SSTU/Assets/SC-TANKS-DIFF-WHITE-S
			texture = _BumpMap, SSTU/Assets/SC-TANKS-NRM-S
			texture = _SpecMap, SSTU/Assets/SC-TANKS-SPEC-S
			texture = _AOMap, SSTU/Assets/SC-TANKS-AO-PIPES
			texture = _MaskTex, SSTU/Assets/SC-TANKS-MASK-STRIPES1
			excludeMesh = FlagTransform
		}
		COLORS
		{
			mainColor = white
			secondColor = black
			detailColor = dkGray
		}
}

Becomes the following (new) config:

@SSTU_MODEL[MFT-A-0-5|MFT-A-1-0|MFT-A-1-5|MFT-A-2-0|MFT-A-2-5|MFT-A-3-0|MFT-A-3-5|MFT-A-4-0|MFT-A-4-5|MFT-A-5-0|MFT-A-5-5|MFT-A-6-0|MFT-A-6-5|MFT-A-7-0|MFT-A-7-5|MFT-A-8-0|MFT-B-0-5|MFT-B-1-0|MFT-B-1-5|MFT-B-2-0|MFT-B-2-5|MFT-B-3-0|MFT-B-3-5|MFT-B-4-0|MFT-B-4-5|MFT-B-5-0|MFT-B-5-5|MFT-B-6-0|MFT-B-6-5|MFT-B-7-0|MFT-B-7-5|MFT-B-8-0]:FOR[SSTU]
{
	KSP_TEXTURE_SET
	{
		name = MFT-Stripes1-Stringers
		title = S1-S
        recolorable = true
		MATERIAL
		{
			shader = SSTU/Masked
			texture = _MainTex, SSTU/Assets/SC-TANKS-DIFF-WHITE-S
			texture = _BumpMap, SSTU/Assets/SC-TANKS-NRM-S
			texture = _SpecMap, SSTU/Assets/SC-TANKS-SPEC-S
			texture = _AOMap, SSTU/Assets/SC-TANKS-AO-PIPES
			texture = _MaskTex, SSTU/Assets/SC-TANKS-MASK-STRIPES1
			excludeMesh = FlagTransform
		}
		COLORS
		{
			mainColor = white
			secondColor = black
			detailColor = dkGray
		}
}

TheUnamusedFox · March 11, 2018

31 minutes ago, Shadowmage said:

Unfortunately there is a lot more that I need to do in order to pack + release TU than with my other mods, which I had... not taken into consideration when posting my intentions yesterday about doing a release today.

Not only do I need to update the actual plugin (the easy part, relatively), but I have to download, setup, and deal with a new Unity Editor version in order to be able to recompile the shaders (Unity shaders are editor/player version-locked). As such, it is going to be delayed until next weekend -- I simply don't have the time to deal with Unity shenanigans today or during the week.

Thank you for sticking with it in spite of your frustration with the update. We really do appreciate all the work you do!

Shadowmage · March 14, 2018

Managed to get TU recompiled and 'working' under KSP 1.4 last night. Certainly some things to sort out and fix up, but all of the major systems are working (some with a few errors).

On to the changes...

In the current releases whenever a material is adjusted by the plugin it does so by taking the current material and simply adjusting whatever properties were set in the config file. This worked fine for standard setups, and allowed for simplified config files as you only needed to define values for those properties that you intended to change. However, it also had problems with value 'bleed-through' -- if you set a property in one texture set, it would persist across all other texture-sets unless that property was also specified in those other texture sets.

In the upcoming releases this will be changed around a bit. Whenever the plugin does material-level manipulation (e.g. texture-set operations), it will start by creating a new material, and then setting any shader properties as defined in the config files. This means that there will be no more value bleed-through across texture set changes. However, it also means that all non default value properties must be specified in the config file for every texture set. You can't create a texture set just to set the metallic property of the shader; you also need to specify what textures to use. As such any configs that made use (abuse) of the 'bleed-through' feature will have to be reworked.

However, I do have a concept for a solution to this new 'problem' -- one that would be to allow for the texture sets to define certain properties as 'inherited'. Any properties marked as inherited in the texture set would be transferred from the original material to the new one. So you could specify a texture set simply to set the metallic property and inherit the texture assignments (or any other property) from the existing material. The inherited property will be taken from whatever the current material is, and not any sort of prefab -- so if you choose to use the inheritance setup, you have to make sure that the property in question is defined in the original material for the part and that the inheritance is specified in all texture sets configs for that model.

After I get this inheritance feature implemented, I'll post some examples of old and new configs, and the best process for converting them / updating them for the new inputs.

Still hoping to get a 'dev testing' version available for KSP 1.4.1 sometime this week/early weekend; something at least usable enough to allow other mods to start updating their configs. Full/stable releases are likely at least another week out. At this point there have been zero changes in the actual shaders, so existing textures and configs should work fine with some minor adjustments, and the update/conversion process for the configs should be not too painful.

Shadowmage · March 14, 2018

Oh my shinies... how I have missed you...

Property inheritance = implemented and working. Obv. I haven't solved the part-icon issues under DX11 (stock issue anyway), but the core of TU and the PBR shaders are still working (at least in the editor; there are some issues with flight-scene reflections yet to be sorted out).

For those who know what they are doing, you can test-drive a KSP 1.4.1 version of TU from the KSP14 branch in the repository. ( https://github.com/shadowmage45/TexturesUnlimited/tree/KSP14 )

Random sample config to show how the inheritance stuff is used (and show a full model-database-manipulating texture set config, using the new config layout and node names).

KSP_MODEL_SHADER
{
	name = Stock_Engine_VectorClusters

	model = Squad/Parts/Engine/Size2LFB/Size2LFB
	model = Squad/Parts/Engine/Size3EngineCluster/Size3EngineCluster

	MATERIAL // Metal
	{
		shader = SSTU/PBR/Metallic

		mesh = Nozzle1
		mesh = Nozzle2
		mesh = Nozzle3
		mesh = Nozzle4
		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		inheritFloat = _FloatPropertyNameHere
		inheritColor = _ColorPropertyNameHere

		PROPERTY
		{
			name = _Metal
			float = 0.75
		}
		PROPERTY
		{
			name = _Smoothness
			float = 0.75
		}
	}
}

Should be able to have a packaged release over the weekend, as long as I can fix up the flight-scene reflection problems (and pending a ton more testing, both internal and external). Not there yet... but progress....

Jimbodiah · March 15, 2018

And those aren't even your parts :wink:

bcink · March 16, 2018

Is the asset bundle based model loading not yet implemented in the test release? Or has something changed perhaps? Thanks

Shadowmage · March 16, 2018

17 minutes ago, bcink said:

Is the asset bundle based model loading not yet implemented in the test release? Or has something changed perhaps? Thanks

It certainly wasn't removed (or even touched), so should still be there. I haven't had a chance to try it out yet, so something in the Unity update may well have broken things there as well. Could even simply be that the asset bundles need to be recompiled with the new Unity editor.

Will know more over the weekend once I can start working on updating SSTU.

bcink · March 16, 2018

17 hours ago, Shadowmage said:

It certainly wasn't removed (or even touched), so should still be there. I haven't had a chance to try it out yet, so something in the Unity update may well have broken things there as well. Could even simply be that the asset bundles need to be recompiled with the new Unity editor.

Will know more over the weekend once I can start working on updating SSTU.

No problem. Fair warning - I think things are mutilated.

Shadowmage · March 16, 2018

1 hour ago, bcink said:

No problem. Fair warning - I think things are mutilated.

Sounds good -- that's what the 'testing releases' are all about -- finding these problems before the 'public' releases.

Thanks for giving it a try, and letting me know there are problems. I'll be taking a look at it either this evening or tomorrow morning, and will make sure to get it working for the first packaged test release (which will likely be Sat. eve or Sun morn).

Shadowmage · March 17, 2018

@bcink

Updated testing version is available in the KSP 1.4 branch, fixes up loading of asset-bundle based models. ( https://github.com/shadowmage45/TexturesUnlimited/tree/KSP14 )

I've verified that the models load, but I've been unable to check on the textures (as my only test case are SSTU parts, and they have other broken plugins preventing textures from loading).

bcink · March 18, 2018

13 hours ago, Shadowmage said:

@bcink

unable to check on the textures

I can confirm everything is working on my end of things (Asset bundle loading and reflective textures patching of meshes).

Ready for 1.4 release

Shadowmage · March 18, 2018

Updated TU Release is available:

https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.1.0.9

Basic recompile for KSP 1.4+. Includes the changes to config node names that I've posted about a few times, so if things seem to be not working, check your configs.

There will be some shader additions coming in the future; both more recoloring PBR shaders and more standard PBR shaders. Should know more on these in the coming weeks.

bcink · March 18, 2018

1 hour ago, Shadowmage said:

Updated TU Release is available:

Thank you for your continued work and for my making my mods possible!!!

Barar · March 19, 2018

Hi Shadowmage,

I've been working on getting your textures unlimited to work on 1.41. I had it working with no problems on 1.3.1, but running into a problem on the latest version. I read through the instructions and changed all the items mentioned like TEXTURE -> MATERIAL, TEXTURESET -> KSP_TEXTURE_SET.

I think I am missing something stupidly obvious because I cannot get it to work. I get the error below in my logs. I currently only have KSP 1.41, Textures Unlimited 1.1.0.9 and ModuleManager.3.0.4 installed.

ERROR: KSPTextureSwitch could not locate texture set for name: Metallic

I have attached my current config and output log in dropbox here: https://db.tt/B2UYZFqZfk

It might be that as quoted below, it is simply not been worked out yet so will need to just wait a few weeks.

15 hours ago, Shadowmage said:

There will be some shader additions coming in the future; both more recoloring PBR shaders and more standard PBR shaders. Should know more on these in the coming weeks.

I appreciate any advice you could spare as the Wiki may not be valid anymore but don't want to take you away from the work you are doing. I can just keep playing 1.3.1 until I learn more about the shaders configs. Thank you again for this mod.

Shadowmage · March 19, 2018

5 hours ago, Barar said:

Hi Shadowmage,

I've been working on getting your textures unlimited to work on 1.41. I had it working with no problems on 1.3.1, but running into a problem on the latest version. I read through the instructions and changed all the items mentioned like TEXTURE -> MATERIAL, TEXTURESET -> KSP_TEXTURE_SET.

I think I am missing something stupidly obvious because I cannot get it to work. I get the error below in my logs. I currently only have KSP 1.41, Textures Unlimited 1.1.0.9 and ModuleManager.3.0.4 installed.

ERROR: KSPTextureSwitch could not locate texture set for name: Metallic

I have attached my current config and output log in dropbox here: https://db.tt/B2UYZFqZfk

It might be that as quoted below, it is simply not been worked out yet so will need to just wait a few weeks.

I appreciate any advice you could spare as the Wiki may not be valid anymore but don't want to take you away from the work you are doing. I can just keep playing 1.3.1 until I learn more about the shaders configs. Thank you again for this mod.

Your texture sets don't have any actual textures assigned. As stated last week -- this will no longer work directly. All properties of a shader are reset to default when assigning a texture set, including textures.

If you want to inherit whatever texture was in a specific slot, you need to explicitly state that in the texture sets. I had posted examples of this last week as well, but have copied it below for reference:

KSP_MODEL_SHADER
{
	name = Stock_Engine_VectorClusters

	model = Squad/Parts/Engine/Size2LFB/Size2LFB
	model = Squad/Parts/Engine/Size3EngineCluster/Size3EngineCluster

	MATERIAL // Metal
	{
		shader = SSTU/PBR/Metallic

		mesh = Nozzle1
		mesh = Nozzle2
		mesh = Nozzle3
		mesh = Nozzle4
		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		inheritFloat = _FloatPropertyNameHere
		inheritColor = _ColorPropertyNameHere

		PROPERTY
		{
			name = _Metal
			float = 0.75
		}
		PROPERTY
		{
			name = _Smoothness
			float = 0.75
		}
	}
}

So you likely just need to add the following to your MATERIAL blocks somewhere:

		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive

This instructs the texture set to use whatever texture was already in that slot. If you are trying to use texture-sets to adjust specific texture properties, all other texture-switch modules targeting that mesh need to inherit the property that is being changed by the other modules.

And lastly, the method in which the texture sets are specified in the modules is incorrect, they should be specified as in the example below... (fully updated with all of the inheritance stuff, but completely untested as I'm at work for the next ~8+ hours)

@REFLECTION_CONFIG[default]
{
	%enabled = true
}

@PART[mk1-3pod]
{
	MODULE
	{
		name = KSPTextureSwitch
		sectionName = Shaders
		currentTextureSet = Metallic
		//single line definition linking this module to an external KSP_TEXTURE_SET node
		textureSet = Metallic
		textureSet = StockMetallicBumped
	}
	MODULE
	{
		name = KSPTextureSwitch
		sectionName = Brightness
		currentTextureSet = Brightness019
		textureSet = Brightness010
		textureSet = Brightness019
	}
	MODULE
	{
		name = KSPTextureSwitch
		sectionName = Metal
		currentTextureSet = Metal100
		textureSet = Metal080
		textureSet = Metal100
	}
	MODULE
	{
		name = KSPTextureSwitch
		sectionName = Smoothness
		currentTextureSet = Smoothness080
		textureSet = Smoothness075
		textureSet = Smoothness080
	}
}


KSP_COLOR_PRESET
{
	name = rgb_gray
	title = RGB Gray
	color = 127,127,127
	specular = 0
	metallic = 0
}

KSP_TEXTURE_SET
{
	name = Metallic
	title = Metallic
	recolorable = false		
	
	MATERIAL
	{
		shader = SSTU/PBR/Metallic
		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		inheritFloat = _Smoothness
		inheritColor = _Color
	}

}

KSP_TEXTURE_SET
{
	name = StockMetallicBumped
	title = StockMetallicBumped
	recolorable = false
	
	MATERIAL
	{
		shader = SSTU/PBR/StockMetallicBumped
		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		inheritFloat = _Smoothness
		inheritColor = _Color
	}

}

KSP_TEXTURE_SET
{
	name = Smoothness075
	title = 075
	recolorable = false

	MATERIAL
	{
		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		inheritFloat = _Metal
		inheritColor = _Color
		
		PROPERTY
		{
			name = _Smoothness
			float = 0.75
		}
	}

}
KSP_TEXTURE_SET
{
	name = Smoothness080
	title = 080
	recolorable = false

	MATERIAL
	{
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		inheritFloat = _Metal
		inheritColor = _Color
		
		PROPERTY
		{
			name = _Smoothness
			float = 0.80
		}
	}

}
KSP_TEXTURE_SET
{
	name = Metal080
	title = 080
	recolorable = false

	MATERIAL
	{		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		inheritColor = _Color
		inheritFloat = _Smoothness
		
		PROPERTY
		{
			name = _Metal
			float = 0.80
		}
	}

}
KSP_TEXTURE_SET
{
	name = Metal100
	title = 100
	recolorable = false

	MATERIAL
	{		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		inheritColor = _Color
		inheritFloat = _Smoothness
		
		PROPERTY
		{
			name = _Metal
			float = 1.00
		}
	}

}

KSP_TEXTURE_SET
{
	name = Brightness010
	title = 010
	recolorable = false

	MATERIAL
	{		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		inheritFloat = _Smoothness
		inheritFloat = _Metal
		
		PROPERTY
		{
			name = _Color
			color = 1.0,1.0,1.0,1.0
		}
	}

}
KSP_TEXTURE_SET
{
	name = Brightness019
	title = 019
	recolorable = false

	MATERIAL
	{		
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		inheritFloat = _Smoothness
		inheritFloat = _Metal
		
		PROPERTY
		{
			name = _Color
			color = 1.9,1.9,1.9,1.0
		}
	}

}

Shadowmage · March 19, 2018

14 hours ago, Barar said:

Hi Shadowmage,

In addition to my previous post, apparently I forgot to write a couple of code blocks for inheriting standard float and color properties (the actual functional bits of the code), so the above config/example won't fully work until I push out an updated TU version.

As it is a fairly large omission, I'll try to get an updated release available within the next couple of days. Apologies for the omission, has been a bit crazy trying to clean up all of the KSP 1.4 breakage across all of my mods.

HafCoJoe · March 19, 2018

How well does Textures Unlimited work in tangent with TRR? Would it make sense to run both? Debating switching WindowShine to use TU instead, though I wouldn't be adding any extra features. Would that make sense? I'm hesitant because I like avoiding more dependencies if I can

Edited March 19, 2018 by Avera9eJoe

Agustin · March 20, 2018

nevermind

Edited March 20, 2018 by Agustin

Barar · March 20, 2018

I am happy my 2am modding attempts is helping you find some issues. Thank you for looking at my config and appreciate all the work you are doing.

Nils277 · March 20, 2018

@Shadowmage Thank you for keeping TU up to date with KSP 1.4.1

I don't really know if this is intentional or not but i have experienced a problem updating to the latest version:

Lets take the following code:

//Adding the PBR shader to the normal parts
@PART[Lynx_*]:NEEDS[TexturesUnlimited] {
	MODULE
	{
		name = KSPTextureSwitch
		sectionName = Appearance
		currentTextureSet = KerbetrotterLtd_Base
		textureSet = KerbetrotterLtd_Base
	}
}

//Default texture setup
KSP_TEXTURE_SET:NEEDS[TexturesUnlimited]
{
	name = KerbetrotterLtd_Base
	title = Standard
	recolorable = false

	//Plastics
	MATERIAL
	{
		shader = SSTU/PBR/StockMetallicBumped
        
		inheritTexture = _MainTex
		inheritTexture = _BumpMap
		inheritTexture = _Emissive
		
		mesh = Base

		PROPERTY
		{
			name = _Metal
			float = 0.0
		}
	}
}

The problem is that there multiple meshes named "Base" in the same part but some use a different texture. In the old systems all mehes keep the texture they have by default. With the new update and the addition of the inheritance they do not. It seems that only the texture from the first found mesh is inherited and then used for all other meshes with the same name. Is this intentional and i have to use different materials?

Edited March 20, 2018 by Nils277

Ger_space · March 20, 2018

9 hours ago, Avera9eJoe said:

How well does Textures Unlimited work in tangent with TRR? Would it make sense to run both? Debating switching WindowShine to use TU instead, though I wouldn't be adding any extra features. Would that make sense? I'm hesitant because I like avoiding more dependencies if I can

They are independend (for now) but we (ShadowMage, HaArLiNsH and me)are in the talks about movong everthing over to TU and leave TRR to the Kerbals only.
To make thinks shiny in TU, you would need to provide an extra map, where you paint the smoothness (and if you want metallic properties)

Metallic levels for the material are controlled by the values in the Red channel of the texture, and the Smoothness levels for the material are controlled by the Alpha channel of the texture. (This means the Green and Blue channels are ignored)

The Map uses the same UV Layout at the normal textures, you you can easily use the basic textures as the template under the layer of the MetalSmooth map. (Or simpley use your WindowShine Maps, and color the RGB channels all black and keep the alpha. Then, if you want, you can add metal information as red color onto it, so you get some nicer effects.

These maps are at least 100% trouble as you don't have to ship altered Squad textures.

Edited March 20, 2018 by Ger_space

HafCoJoe · March 20, 2018

3 hours ago, Ger_space said:

They are independend (for now) but we (ShadowMage, HaArLiNsH and me)are in the talks about movong everthing over to TU and leave TRR to the Kerbals only.
To make thinks shiny in TU, you would need to provide an extra map, where you paint the smoothness (and if you want metallic properties)

Metallic levels for the material are controlled by the values in the Red channel of the texture, and the Smoothness levels for the material are controlled by the Alpha channel of the texture. (This means the Green and Blue channels are ignored)

The Map uses the same UV Layout at the normal textures, you you can easily use the basic textures as the template under the layer of the MetalSmooth map. (Or simpley use your WindowShine Maps, and color the RGB channels all black and keep the alpha. Then, if you want, you can add metal information as red color onto it, so you get some nicer effects.

These maps are at least 100% trouble as you don't have to ship altered Squad textures.

Hm, I'm heavily reliant on TRR for a different reason since I use it to replace the skybox and add visor reflections. While TU is far superior for part reflections, I don't want to create a new texture for every single part. If it was a quick "load up a texture, change its hue to red, and call it good" then I might but I can say already that I don't have the skill to create new textures from scratch; I'm just a guy with paint.net and some practice with config files

Edited March 20, 2018 by Avera9eJoe

Shadowmage · March 20, 2018

6 hours ago, Nils277 said:

The problem is that there multiple meshes named "Base" in the same part but some use a different texture.

Hmm.. that would be problematic, but probably not compatible with any texture switching mods.

I should probably add to the OP that 'uniquely named transforms' are necessary for proper per-transform/per-mesh texture handling.

6 hours ago, Nils277 said:

It seems that only the texture from the first found mesh is inherited and then used for all other meshes with the same name.

Yes, for a given MATERIAL, it will use the first texture found for all other uses of that MATERIAL.

6 hours ago, Nils277 said:

Is this intentional and i have to use different materials?

Yes. If you need different textures to be used/inherited, you need different MATERIAL blocks that target different meshes.

This change was a direct result of a fix for the exact loophole that these types of property-only 'texture sets' were (ab)using (property values carrying across textures sets). https://github.com/shadowmage45/TexturesUnlimited/issues/35

The MATERIAL definitions now work kind of like an actual Material instance in Unity -- a single Material can be applied to multiple meshes, but they all will share textures/etc (and that is what they directly map to in the code).

14 hours ago, Avera9eJoe said:

How well does Textures Unlimited work in tangent with TRR? Would it make sense to run both? Debating switching WindowShine to use TU instead, though I wouldn't be adding any extra features. Would that make sense? I'm hesitant because I like avoiding more dependencies if I can

I think if it all works out, you should be able to switch your dependency from TRR to TU. TU will have all of the shaders and reflection-probe handling code, so you should be able to use those as needed.

Have you checked out the TU 'stock conversion' patches that have been floating around? They pretty much already do all of the window-reflection related stuff, with just a simple config/MM patch (if you already had existing additional texture maps for the stock parts, can likely make use of those too for even better effects)

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation