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

[Shadowmage]

4 minutes ago, Arco123 said:

How do you get these to work?

Magic

More seriously, you have to provide a thickness texture that denotes the 'thickness' and light-transmission color of the geometry, enable the keyword in the texture-set config for SubSurfaceScattering, add values for the subsurface scattering properties, and enjoy the glowy effects...

Here is the texture set config for that part:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Data/TextureSets/updated/DefaultShaderAssignments-SolarPanels.cfg#L1-L34

KSP_MODEL_SHADER
{
	name = SSTU/Assets/ST-GEN-DSP-ISS
	model = SSTU/Assets/ST-GEN-DSP-ISS
	MATERIAL
	{
		shader = TU/Metallic
		texture = _MainTex, SSTU/Assets/ST-GEN-DSP-ISS-DIFF
		texture = _BumpMap, SSTU/Assets/ST-GEN-DSP-ISS-NRM
		texture = _MetallicGlossMap, SSTU/Assets/ST-GEN-DSP-ISS-MET
		texture = _Thickness, SSTU/Assets/ST-GEN-DSP-ISS-GLOW
		texture = _AOMap, SSTU/Assets/ST-GEN-DSP-ISS-AO
		excludeMesh = ST-GEN-DSP-ISS
		excludeMesh = ST-DSP-ISS-Base
		excludeMesh = ST-DSP-ISS-TopCap
		keyword = TU_SUBSURF
		float = _SubSurfAmbient,0.2
		float = _SubSurfScale,3.0
		float = _SubSurfPower,6.0
		float = _SubSurfDistort,0.0
		float = _SubSurfAtten,1.0
	}
	MATERIAL
	{
		shader = TU/Metallic
		texture = _MainTex, SSTU/Assets/ST-GEN-DSP-ISS-DIFF
		texture = _BumpMap, SSTU/Assets/ST-GEN-DSP-ISS-NRM
		texture = _MetallicGlossMap, SSTU/Assets/ST-GEN-DSP-ISS-MET
		texture = _AOMap, SSTU/Assets/ST-GEN-DSP-ISS-AO
		mesh = ST-GEN-DSP-ISS
		mesh = ST-DSP-ISS-Base
		mesh = ST-DSP-ISS-TopCap
	}
}

Thickness texture:

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Assets/ST-GEN-DSP-ISS-GLOW.dds

 

In short, you are not going to just 'get it to work' on any stock or other mods' parts; it requires considerable effort to set it up properly for already-existing parts (e.g. stock/other mods), mostly involved in the creation of the thickness texture(s).  This again goes back to the fact that TU was intended for mod authors to use in their workflow, where they have access to all of the assets needed to create the extra textures and configs, and it isn't nearly as much work (e.g. they already have UV maps and diffuse/specular textures to base the thickness texture on).

The SubSurfaceScattering included in TU is based on the work presented here:  https://www.alanzucconi.com/2017/08/30/fast-subsurface-scattering-1/  which is further based on the GDC 2011 presentation, as implemented in the FrostBite engine, available here: https://colinbarrebrisebois.com/2011/03/07/gdc-2011-approximating-translucency-for-a-fast-cheap-and-convincing-subsurface-scattering-look/

If you wanted to fully understand the effect and its implementation/use/configuration, I would highly suggest giving both of those links a good read-through.

[Delay]

@Shadowmage My solar panels look like this. It doesn't really look all that good in my opinion.

I'm only using a grayscale picture to dictate thickness. According to the documentation you can use colors in that map too?

[Shadowmage]

Just now, Delay said:

According to the documentation you can use colors in that map too?

Yes.  That is exactly what SSTU uses for its solar panels, a full RBG thickness texture (aka colored lighting transmission map) (here is the actual image used by the SSTU solar panels, extracted and decompressed from the link above):

 

You should also play with the subsurface scattering parameters, as they can have a major impact on the final effect.

Best way to set these up is to play around with them in the Unity Editor, where you can use the TU shaders directly, and play with the settings in real-time; its not the most straightforward process to setup, but is great for testing of setting such as these (and is the exact process I used to configure those parts).  If this is something you might be interested in, let me know and I can guide you through the setup process (currently not documented anywhere, as so far, no actual mod authors have expressed any interest in TU, and as this setup requires access to the original models and textures, it is not something that stock-patch-authors generally have access to....).

[Manwith Noname]

15 hours ago, Uohcnam said:

Here is the config i created, i use only this mod (except TU and MM), i'm on KSP 1.7.3 and i try to setup tu on the I Beam 200 strutural part.

@REFLECTION_CONFIG[Default]:NEEDS[TexturesUnlimited]
{
	%enabled = true
}

 

For KSP 1.7.x releases of TexturesUnlimited, I'm reasonably sure you don't need this part. Things changed and TU defers to using stock controls.

 

15 hours ago, Uohcnam said:

Then, after testing some recoloring / switching config, i'd like to explore this mod by creating my own config for my personnal usage.

Can I ask, how far do you intend to go and do you ever imagine you would want to release this?

I ask because I've structured the recolour pack a specific way to reduce the amount of work others might need to do to add more sets and also allow every pack to play nice with each other. I'm not saying you have to but this is ultimately the reason for TURD being structured the way it is. Without some sort of "standardisation", everyone will be limited to just choosing a single pack. With standardisation, everyone can focus on making their own pack as an addon. The "Standardised Switching", was always intended to become its own download for this purpose.

Essentially, you don't need to apply the stock setups because that's already done. You can take the metallic config or the recolour config and with a bit of renaming plus find and replace, you have an entire template to go through and all that needs to happen is pointing texture paths to your own.

[Delay]

Looking much better now! Thanks!

I'll have to continue fiddling around with the numbers a bit, but this is already looking much more believable than before.

[Shadowmage]

5 minutes ago, Delay said:

Looking much better now! Thanks!
 

I'll have to continue fiddling around with the numbers a bit, but this is already looking much more believable than before.

Glad that worked out for you   Yeah, I'd definitely fiddle with the parameters a bit, notably the 'float = _SubSurfScale,3.0' and  'float = _SubSurfPower,6.0' parameters, as they have a massive influence on the final lighting rendering.

Take pleasure in knowing that whatever you create that uses this effect, will be quite unique in the realm of KSP mods.  Aside from SSTU, this is the first and only other use of the subsurface scattering effect that I've seen, and I'm not aware of any other mods that add subsurface scattering to KSP.

 

17 minutes ago, Manwith Noname said:

For KSP 1.7.x releases of TexturesUnlimited, I'm reasonably sure you don't need this part. Things changed and TU defers to using stock controls.

100% correct.  That patch is no longer needed; instead you should enable the stock reflection settings in the stock game options menu.

[Manwith Noname]

1 hour ago, Shadowmage said:

Aside from SSTU, this is the first and only other use of the subsurface scattering effect that I've seen, and I'm not aware of any other mods that add subsurface scattering to KSP.

I started but shelved it to come back to...

Spoiler

+KSP_TEXTURE_SET[MWNN_Stock_Paint]:NEEDS[TexturesUnlimited&!Restock]
{
	@name = MWNN_Stock_Paint_largeSolarPanel_Panel
	@MATERIAL
	{
		mesh = panel
		
		vector = _DiffuseNorm,0.74,0.74,0.74
		vector = _MetalNorm,0.5,0.5,0.5
		vector = _SmoothnessNorm,0.5,0.5,0.5
		
		texture = _MainTex,Squad/Parts/Electrical/gigantorXlSolarArray/panel
		texture = _BumpMap,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Bump
		texture = _Emissive,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Emis
		texture = _AOMap,TURD/TU_Standardised_Switching/000_PlaceholderTextures/Occ
		texture = _MetallicGlossMap,TURD/TU_Stock_Recolour/Electrical/Gigantor XL Solar Array/173_largeSolarPanel_Spec
		texture = _MaskTex,TURD/TU_Stock_Recolour/Electrical/Gigantor XL Solar Array/173_largeSolarPanel_Paint
		
		// texture = _Thickness,TURD/TU_Stock_Recolour/Electrical/Gigantor XL Solar Array/173_largeSolarPanel_Thick
		// keyword = TU_SUBSURF
		// float = _SubSurfAmbient, 0
		// float = _SubSurfScale, 1
		// float = _SubSurfPower, 1
		// float = _SubSurfDistortion, 0
		// float = _SubSurfAttenuation, 1
	}
}

 

There was bigger fish to fry at the time.

Edited March 6, 2020 by Manwith Noname

[Uohcnam]

19 hours ago, Manwith Noname said:

Can I ask, how far do you intend to go and do you ever imagine you would want to release this?

Hi!

I don't want to release anything. For now, i just learn some modding mechanics. i'm interesting the way how mods are made. Later ... maybe ... if i've mod idea, i'll use this knowledge.
I know the huge work you've done withe the stock config! it's well organize, and know i understand how TU, MM and KSP config work, it's easy to use! 

That's all ;D 

[Manwith Noname]

56 minutes ago, Uohcnam said:

For now, i just learn some modding mechanics. i'm interesting the way how mods are made. Later ... maybe ... if i've mod idea, i'll use this knowledge.

Yeah, I thought that might be the case, it's good to dismantle everything for learning purposes. I just thought I'd let you know that there is a way to reduce the amount of work and that is the intended purpose of certain parts within the recolour pack. Essentially, it's modular but provided in a single download for convenience.

While I'm here...

@Shadowmage Is there a way I haven't found that enables a material block to display as separate colour controls within the GUI? In the past, I've worked around this with multiple texture switch modules but on the new engines, I kinda have to use part variants due to the game object switching and ideally, I'd like to have more than three "colour" options. I tried using multiple part variant switchers so one would handle only the object changes and the other would flick between shaders and texture sets but this broke the game, haha. Well, it loaded but the editor scenes didn't like it one bit.

 

[Gaalidas]

On 3/3/2020 at 1:46 PM, Shadowmage said:

No doubt C++ is better suited for the implementation of specific functions, or for use in specific performance-critical places; but a general purpose scripting language, it is not.

My only use for it is in the area of C# not being able to return anything to the process that runs it.  You'd have to export something to a file and read it from the calling process, like a batch file or something.  So, when i try to expand my batch files to use C# methods... I can't provide any success or fail feedback without a bunch of work.

Edited March 6, 2020 by Gaalidas

[Shadowmage]

1 hour ago, Manwith Noname said:

Is there a way I haven't found that enables a material block to display as separate colour controls within the GUI?

No.

1 hour ago, Manwith Noname said:

In the past, I've worked around this with multiple texture switch modules

That is how it is accomplished.

1 hour ago, Manwith Noname said:

use part variants

Oh, well, there is the problem... (have I ever mentioned my loathing for the PartVariant system? well...)

The stock PartVariant system is really not modular, nor is it intended for mods to interact with it from the code-side, so my ability to fix issues with it is extremely minimal.

Might be able to use multiple TUPartVariant modules?  Can't guarantee it would work right now, but I might be able to make some changes to allow it to function... (you would specify the same texture-sets in each, with different root transforms); would have to examine the data and how to make it all work on the back side of things.  I would say to open an issue ticket for the feature request, and I will examine it for my next round of TU updates (might be a few weeks, need to get my other mods updated to 1.9 and fix a few issues in some of them).

[Shadowmage]

2 hours ago, Manwith Noname said:

Is there a way I haven't found that enables a material block to display as separate colour controls within the GUI?

I should add that I've also given this some thought in the past, as in some way to specify a second mask texture, a second set of user input values, and a second set of normalization parameters.  The problem is that at some point, the shader becomes so complex, that you run out of registers (hardware) to store parameters, and end up absolutely killing performance (it will still work, but ends up using shared memory for registers, which is slow-as-dirt comparatively).

[Manwith Noname]

2 hours ago, Shadowmage said:

Oh, well, there is the problem... (have I ever mentioned my loathing for the PartVariant system? well...)

Indeed, you're not alone. Every time a new part appears using it I die a little inside. I wouldn't worry about it too much, I just figured I'd ask the question before I get to the point with them where I'm making the masks and planning it all out. Well, I've configured things the simple way for now but haven't plotted out the textures. I've also had an idea knocking around in my head for nearly a year on how I can most likely get around this but I've never tested it out. I might try it and weigh up the pros and cons.

 

2 hours ago, Shadowmage said:

I should add that I've also given this some thought in the past, as in some way to specify a second mask texture, a second set of user input values, and a second set of normalization parameters.  The problem is that at some point, the shader becomes so complex, that you run out of registers (hardware) to store parameters, and end up absolutely killing performance (it will still work, but ends up using shared memory for registers, which is slow-as-dirt comparatively).

I suspect you're thinking in regards to a single mesh object? I have essentially been doing this through material blocks where more than one mesh exists and in most cases, it's been fine following the main three colours / materials simply due to the general design of the part and how I have wanted things to "flow".

[Shadowmage]

Just going to leave these here for the evening...

(its nearly ready...)

[Delay]

@Shadowmage So, it seems like the Transparent/Metallic shader is not handled properly, in both the SPH/VAB and in-flight scenes.

The first one is the picture of the launch clamp I posted yesterday. Using just a metallic shader works fine, so it's definitely the transparency that causes the problems.

The supports (only the supports use the transparency) don't have to disappear entirely, sometimes they are rendered behind things they are supposed to be in front of instead. What they render behind can also change depending on the camera angle and for some very specific angles it renders right where it should.

Perhaps related to this, or even caused by the same thing, is the disappearance of texts and symbols if they are on a transparent plane. Some parts do this instead of simply putting the symbol directly on the mesh. This is also dependent on the camera position:

(This also happens in-flight):

Spoiler

There's another weird behavior of the transparent shader, and it is scene dependent and only seems to happen in the editors. Since I don't see any connection to the main issue and since it works just fine outside of SPH and VAB I've put this issue in a spoiler.

Spoiler

If a transparent mesh is very brightly lit, as it would be in the SPH if it faces up, the entire mesh is completely white.

Note this does not happen in-flight, not even at noon.

I suppose that's all the information that is useful here. If anything else is required, let me know.

 

[Shadowmage]

@Delay

Two things I can think of right off the bat;

1.) Transparent objects should use the TU/Transparent/Metallic shader
2.) Try setting the renderQueue in the material blocks -- https://docs.unity3d.com/ScriptReference/Rendering.RenderQueue.html and https://docs.unity3d.com/Manual/SL-SubShaderTags.html

Example:

MATERIAL
{
	shader = TU/Transparent/Metallic
	//other properties
	renderQueue = 3010
	// or 2090...
}

If neither of those built-in options do the trick, let me know and I can investigate further...

[Delay]

21 minutes ago, Shadowmage said:

renderQueue = 3010

Is that syntax correct? If it is, then it doesn't look like it is of much use. I even tried 4000, which would render it as an overlay and it is still blocked.

TU/Transparent/Metallic is used anyways.

[Shadowmage]

Just now, Delay said:

Is that syntax correct

IDK, should be; lemme double check in the source... (never had to use it; added it for others to use, and there it has remained)

Yeah, looks correct from the source code. 

renderQueue = node.GetIntValue("renderQueue", (TexturesUnlimitedLoader.isTransparentShader(shader)? (int)RenderQueue.Transparent : (int)RenderQueue.Geometry));

Will use the value specified, if specified, else will use the standard geometry or transparent values...

 

What would be needed for a minimal reproduction setup? (e.g. is there a config for stock parts that shows this?)

[Delay]

42 minutes ago, Shadowmage said:

What would be needed for a minimal reproduction setup? (e.g. is there a config for stock parts that shows this?)

I guess the reason the clamps are obscured is the same as for the symbols disappearing. So literally any transparency mesh - like the FLAG mesh for the command modules - should cause this bug.

I have, however, made this patch for the stock launch clamp:

KSP_TEXTURE_SET
{
	name = LaunchClamp1
	MATERIAL
	{
		shader = TU/Metallic
		PROPERTY
		{
			name = _Metal
			float = 0.5
		}
		PROPERTY
		{
			name = _Smoothness
			float = 0.3
		}
		excludeMesh = obj_girdercap_mesh
		excludeMesh = obj_girder_mesh
		texture = _MainTex, Squad/Parts/Utility/launchClamp1/model000
	}
	MATERIAL
	{
		shader = TU/Transparent/Metallic
		PROPERTY
		{
			name = _Metal
			float = 0.5
		}
		PROPERTY
		{
			name = _Smoothness
			float = 0.3
		}
		mesh = obj_girdercap_mesh
		mesh = obj_girder_mesh
		texture = _MainTex, Squad/Parts/Utility/launchClamp1/model001
	}
}

@PART[launchClamp1]
{
	MODULE
	{
		name = KSPTextureSwitch
		textureSet = LaunchClamp1
	}
}

 

[Shadowmage]

It is done....

 

[Manwith Noname]

Hold up...wait a minute...

This was mentioned in passing during a conversation and, well...

Spoiler

Light sources now show up at full spec it seems. Unity? KSP? TU? or all of the above?!

 

Edit: I'm suspecting the recent camera changes.

Edited March 13, 2020 by Manwith Noname

[New Horizons]

Which versions are supported by the latest update 1.5.10.25?

The version file is a bit confusing. Can I us this on KSP 1.8.1?

	"VERSION":
	{
		"MAJOR":1,
		"MINOR":5,
		"PATCH":10,
		"BUILD":25
	},
	"KSP_VERSION":
	{
		"MAJOR":1,
		"MINOR":9,
		"PATCH":0
	},
	"KSP_VERSION_MIN":
	{
		"MAJOR":1,
		"MINOR":9,
		"PATCH":0
	},
	"KSP_VERSION_MAX":
	{
		"MAJOR":1,
		"MINOR":8,
		"PATCH":9
	}
}

 

[Shadowmage]

On 3/12/2020 at 8:41 PM, Manwith Noname said:

Edit: I'm suspecting the recent camera changes.

Yeah, I'm suspecting you are correct; or rather, they now included previously un-rendered layers in the ReflectionProbe, and/or increased its far-clip to cover the larger distance.

On 3/22/2020 at 3:35 PM, New Horizons said:

Which versions are supported by the latest update 1.5.10.25?

Should work fine in...KSP1.6+? (dunno, don't test older versions...)

Yes, there is a typo in the .version file, that last line (KSP_VERSION_MAX) should also be referencing KSP 1.9.9

[New Horizons]

On 3/25/2020 at 6:31 PM, Shadowmage said:

Yeah, I'm suspecting you are correct; or rather, they now included previously un-rendered layers in the ReflectionProbe, and/or increased its far-clip to cover the larger distance.

Should work fine in...KSP1.6+? (dunno, don't test older versions...)

Yes, there is a typo in the .version file, that last line (KSP_VERSION_MAX) should also be referencing KSP 1.9.9

And is there a typo in VERSION_MIN, too?

[Shadowmage]

40 minutes ago, New Horizons said:

And is there a typo in VERSION_MIN, too?

IDK, maybe?  It should have 1.9.0 as the min version; I don't support older KSP versions (doesn't mean it won't work, I just don't test it, and I'm not offering support).