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

[HafCoJoe]

3 hours ago, Shadowmage said:

 

 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)

Stock Conversion patches? I've not heard of them no... Might need to look into this more. Know who I should contact if I wanted to use these pre-made window configs?

[Shadowmage]

6 minutes ago, Avera9eJoe said:

Stock Conversion patches? I've not heard of them no... Might need to look into this more. Know who I should contact if I wanted to use these pre-made window configs?

@Electrocutor is the author of the one that I personally use.

 

https://forum.kerbalspaceprogram.com/index.php?/topic/168795-electrocutors-thread/

 

[Shadowmage]

15 minutes ago, Avera9eJoe said:

Stock Conversion patches? I've not heard of them no... Might need to look into this more. Know who I should contact if I wanted to use these pre-made window configs?

@Electrocutor is the author of the one that I personally use.

@Manwith Noname Also has a few configs for various mods.

 

They can be found here:

 

And a link to the KSP 1.3.1 stock conversion patch is here:

https://drive.google.com/open?id=1QGANnsrxPjq4tIpKjCsuFbFjv9F1rml5

 

A couple previews of parts using the stock-conversion patch:

 

Edit:  Wonderful forum software....

 

Edited March 20, 2018 by Shadowmage

[Shadowmage]

Just a quick heads up -- Will be pushing out an updated release tonight that fixes the float and color property inheritance features.  Shouldn't have any other changes (though I'm considering adding capability to load the old config-node naming, just for compatibility sake).

If anyone is aware of any other new issues that need fixing -- now is the time to speak up

[Jimbodiah]

Any chance of Electro or Noname adding their stock patches into the TU release (future releases anyway).

[Shadowmage]

14 minutes ago, Jimbodiah said:

Any chance of Electro or Noname adding their stock patches into the TU release (future releases anyway).

No.  Just as ModuleManager doesn't ship anyone's personal patch configs, neither will TU ship anyone's personal texture-set configs.  It is not my place to decide how the parts should look in someone's personal game, just as it is not ModuleManager's place to decide what ISP an engine should use, or how much fuel a tank should hold.  Another example of a neutral API would be KSPWheel -- if added to a game by itself, it does absolutely nothing; and the same reasoning is why it doesn't ship with patches to KSPWheel-ize the stock parts.

(not trying to say that TU is on the same level of utility, usefulness, or stability as ModuleManager, merely pointing out that both are intended as neutral APIs that by themselves should not effect anything; they exist to allow others to do things)

 

Please don't take this statement as me saying that I don't appreciate the work put into those patches, or that I disagree with the outcomes -- neither is true.  I fully appreciate the patches they have put together, and in fact use (some of) them in my own personal games.  I fully support and endorse their work; I just don't think it would be proper to distribute it with the base TU releases.  I don't even have any objections to distributing those patches from the TU repository as separate (optional) downloads, so that might be an option in the future. 

There -might- also be an option for a 'TU-Deluxe' release that included configs at some point in the future -- but I don't really have time to look into it for awhile, and it would of course still depend on the willingness of the authors to have their work distributed with TU.

Edited March 21, 2018 by Shadowmage

[Shadowmage]

Updated release is available:

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

Fixes the missing/broken color and float property inheritance.  Really not any other changes.

[Electrocutor]

Here's some discovery...

		VARIANT {
			name = Vens
			themeName = Vens
			
			TEXTURE {
				shader = KSP/Bumped Specular
				_BumpMap = KSPCF/Parts/Assets/Mesh_NRM
			}
		}

The above works; however, it does not find the SSTU shaders; so you'd need to figure out how to get them registered into Unity in such a way that they are found by KSP.

 

Unfortunately, it appears that COLOR{}, FLOAT{}, and VECTOR{} do nothing, so the extent of KSP Variants is:

• Change the part shader to one of KSP's internal shaders
• Change the textures of the part material
• Hide or Show submeshes within the part model

I think I'm done tinkering with this variant stuff now as it's mostly unusable for mods unless you just want to change a texture. I'm going to see if I can intercept the calls to ModulePartVariants and just write it myself to be useful. It'd be best to try to keep the GUI clean by not stacking multiple right-click menu buttons, texts, etc for different types of visual customization.

Edited March 22, 2018 by Electrocutor

[skyhawkmlt]

Is this really working with 1.4.1, is there anything I need to do? Anything else I need to install to be able to see pbr and reflections? I've checked the cfg and enabled global reflections, still can't see any difference. I even tried setting game to dx11

[Theysen]

12 minutes ago, skyhawkmlt said:

Is this really working with 1.4.1, is there anything I need to do? Anything else I need to install to be able to see pbr and reflections? I've checked the cfg and enabled global reflections, still can't see any difference. I even tried setting game to dx11

This mod here itself only offers a framework for other people's parts and / or configs to use the functions TexturesUnlimited offers. 

You need to install those parts or configs, examples are given in the forum op, the documentation about how to add them to models yourself is also given in the op. 

 

 

[skyhawkmlt]

4 minutes ago, Theysen said:

This mod here itself only offers a framework for other people's parts and / or configs to use the functions TexturesUnlimited offers. 

You need to install those parts or configs, examples are given in the forum op, the documentation about how to add them to models yourself is also given in the op. 

 

 

is there a script to make it work with default parts of 1.4.1?

[Shadowmage]

8 hours ago, Electrocutor said:

You may want to revert your choice to create a new Material as opposed to changing properties on the existing one. This has introduced a lot of other mod incompatibilities that were not an issue before, such as B9PartSwitch, FSTextureSwitch, JSI, etc.

As this change was a direct response to a problem you were having (values persisting across texture sets - https://github.com/shadowmage45/TexturesUnlimited/issues/35), would adding a 'mode' field to the texture-set definitions be a usable compromise?  (although I still don't see why someone would try to use multiple texture-switch modules from different mods on a single part...)

The mode field would be a simple enum with only two options - 'create' and 'update'.  When 'mode = create' is specified in the texture set definition, it would work exactly as it does now (create a new material, with optional inheritance of properties); when 'mode=update' is specified, it would merely update only the properties specified in the texture set definition, leaving all other values intact (e.g. exactly as it functioned in KSP-131 versions).

Default value would be: ?? (really doesn't matter to me; all of the texture set configs I write explicitly define all properties, so this was never a problem that I needed solved)

 

1 hour ago, skyhawkmlt said:

is there a script to make it work with default parts of 1.4.1?

Probably not yet.  The API (this mod) was just barely updated and made available for 1.4.1 in the last few days -- you need to give the other mod authors time to update their configs.

[Electrocutor]

2 minutes ago, Shadowmage said:

As this change was a direct response to a problem you were having (values persisting across texture sets - https://github.com/shadowmage45/TexturesUnlimited/issues/35), would adding a 'mode' field to the texture-set definitions be a usable compromise?  (although I still don't see why someone would try to use multiple texture-switch modules from different mods on a single part...)

The mode field would be a simple enum with only two options - 'create' and 'update'.  When 'mode = create' is specified in the texture set definition, it would work exactly as it does now (create a new material, with optional inheritance of properties); when 'mode=update' is specified, it would merely update only the properties specified in the texture set definition, leaving all other values intact (e.g. exactly as it functioned in KSP-131 versions).

Default value would be: ?? (really doesn't matter to me; all of the texture set configs I write explicitly define all properties, so this was never a problem that I needed solved)

The key is that having to specify inheritance for every property is way too much cfg spam and busywork; for a quick solution, perhaps simply having default be using existing material, but have an option to specify like newMaterial = true or whatever to change the behavior if you need it.

[Shadowmage]

9 hours ago, Electrocutor said:

The above works; however, it does not find the SSTU shaders; so you'd need to figure out how to get them registered into Unity in such a way that they are found by KSP.

Indeed... I've never found a solution to this problem.  I'm not sure its even possible from C# code -- all of the Unity C# .dlls are simply wrappers around native function calls into C++ code.

 

9 hours ago, Electrocutor said:

I think I'm done tinkering with this variant stuff now as it's mostly unusable for mods unless you just want to change a texture.

That was pretty much my take on the new feature -- sufficient for stock purposes, but has major deficiencies if attempting to use it for anything more complex.

 

[Shadowmage]

31 minutes ago, Electrocutor said:

The key is that having to specify inheritance for every property is way too much cfg spam and busywork; for a quick solution, perhaps simply having default be using existing material, but have an option to specify like newMaterial = true or whatever to change the behavior if you need it.

Done.

Each MATERIAL block now has an additional field for 'mode' (string data type).  Valid options are 'create', and 'update'.  Default value (if no 'mode' line is found in the config) is 'update', which is basically the same functionality as in the KSP 1.3.1 versions.  In texture sets that use multiple MATERIAL blocks you can even use different modes in each block independently.  I also added a tiny bit of code to still allow for loading of the TEXTURE named material blocks (e.g. old style configs from KSP 131).

In short:  it should now load your old configs without any changes.  Should.  Completely untested.

 

As there were apparently some merge errors that I didn't catch in the release last night, I've packed up an updated release (and removed all of the problematic ones) -- https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.1.0.11

[Electrocutor]

Thanks. The mod is still throwing some exceptions though:

[ERR 16:27:51.759] Exception handling event OnPartLoaderLoaded in class TexturesUnlimitedLoader:System.NullReferenceException: Object reference not set to an instance of an object
  at KSPShaderTools.TexturesUnlimitedLoader.applyToPartIcons () [0x00000] in <filename unknown>:0 

[LOG 16:28:16.986] SSTUReflectionManager created camera: TRReflectionCamera (UnityEngine.Camera)
[EXC 16:28:16.988] MissingMethodException: Method not found: 'UnityEngine.RenderTexture.set_generateMips'.

 

[Shadowmage]

24 minutes ago, Electrocutor said:

Thanks. The mod is still throwing some exceptions though:

[ERR 16:27:51.759] Exception handling event OnPartLoaderLoaded in class TexturesUnlimitedLoader:System.NullReferenceException: Object reference not set to an instance of an object
  at KSPShaderTools.TexturesUnlimitedLoader.applyToPartIcons () [0x00000] in <filename unknown>:0 

[LOG 16:28:16.986] SSTUReflectionManager created camera: TRReflectionCamera (UnityEngine.Camera)
[EXC 16:28:16.988] MissingMethodException: Method not found: 'UnityEngine.RenderTexture.set_generateMips'.

 

Hmm... and more hmmm....

Is this with any specific patch/config file, or just when adding the mod by itself?

(at a bit of a loss on the second error, as I specifically (re)fixed that incorrect method today, after the original fix was lost during bad branch update)

 

Edit:  Have removed all 1.4+ release versions, and re-flagged the OP as only being 1.3.1 compatible.  I'll have to look into fixing all of this when I actually have time to work on and test stuff; right now I'm trying to squeeze in dev time during lunch/etc at work, where time is very limited and I have no ability to launch KSP to test things. 

Edited March 22, 2018 by Shadowmage

[Electrocutor]

Just now, Shadowmage said:

Hmm... and more hmmm....

Is this with any specific patch/config file, or just when adding the mod by itself?

(at a bit of a loss on the second error, as I specifically (re)fixed that incorrect method today, after the original fix was lost during bad branch update)

clean install with reflections set to true; no cfgs or anything.

[Shadowmage]

18 minutes ago, Electrocutor said:

clean install with reflections set to true; no cfgs or anything.

Thanks.  I'll see what I can do to recompile and repack after I get home (and before I have to go off to other things...).

I have a feeling that my KSP libs have gotten out of synch across my various dev environments; which would explain why I wasn't seeing the problem when I did a branch review and examined the commits....

(would be so much nicer if I could just commit the libs into the repo... but copyrights...blah...)

[Shadowmage]

Lets try this again.... (this time after some testing...)

Updated release is available:

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

Fixes up the fubar'd mess from the past couple of days and releases.

Successfully loads @Electrocutor's legacy stock conversion patch that I borrowed from my KSP 1.3.1 install, without any edits or updates, so should load all other existing configs as well.

(yes, the part list is full of broken parts; that is what SSTU looks like at the moment )

[Vandest]

First, your mod is awesome! Best render ever seen!

I predict it will be a must have. (more like scatterer than ModuleManager )

I've tested the old stock config file of @Electrocutor with the latest TU (1.1.0.12), and I'm happy to see that bump maps are there in game (I couldn't manage to got them with 1.1.0.10 and my modified config file).

But I've an issue with the FlagDecal, at a certain angle the main texture become transparent, see pic:

Do you know if I can avoid it? If yes, how?

 

My KSP Infos:

• KSPx64 DX11
• DirectX 11-12 Fix
• TexturesUnlimited-1.1.0.12
• TexturesUnlimited_Stock.cfg

 

Edited March 23, 2018 by Vandest

[Electrocutor]

Does the new syntax not allow shared texture sets like so (at the root of the file instead of under an @PART)?

KSP_TEXTURE_SET
{
	name = PorkjetStock_DefaultMetal
	title = Default Metal
	recolorable = false

	MATERIAL
	{
		shader = SSTU/PBR/StockMetallicBumped

		excludeMesh = FLAG
		excludeMesh = flare
		excludeMesh = Flare

		PROPERTY
		{
			name = _Color
			color = 1.75,1.75,1.75
		}
		PROPERTY
		{
			name = _Metal
			float = 0.75
		}
		PROPERTY
		{
			name = _Smoothness
			float = 1.0
		}
	}
	COLORS
	{
		mainColor = rgb_gray
		secondColor = rgb_gray
		detailColor = rgb_gray
	}
}

 

[LOG 07:56:33.789] ERROR: KSPTextureSwitch could not locate texture set for name: PorkjetStock_DefaultMetal

 

Edited March 23, 2018 by Electrocutor

[Manwith Noname]

It does, check the config I sent you via PM to see what needs changing. Actually...

TEXTURESET
{
	name = blah blah
}

...now needs to be a line in the module the texture switch module...

textureSet = blah blah

Edit: Not sure if pings work from edits but...

@Electrocutor

Edited March 23, 2018 by Manwith Noname

[Shadowmage]

8 hours ago, Vandest said:

Do you know if I can avoid it? If yes, how?

 

My KSP Infos:

• KSPx64 DX11
• DirectX 11-12 Fix
• TexturesUnlimited-1.1.0.12
• TexturesUnlimited_Stock.cfg

Sounds like a legitimate bug to me; I'll see what I can do to clean it up for a future release.  https://github.com/shadowmage45/TexturesUnlimited/issues/44

Until then you can likely just disable the flags on the parts.

[Electrocutor]

8 hours ago, Vandest said:

First, your mod is awesome! Best render ever seen!

I predict it will be a must have. (more like scatterer than ModuleManager )

I've tested the old stock config file of @Electrocutor with the latest TU (1.1.0.12), and I'm happy to see that bump maps are there in game (I couldn't manage to got them with 1.1.0.10 and my modified config file).

But I've an issue with the FlagDecal, at a certain angle the main texture become transparent, see pic: 

Do you know if I can avoid it? If yes, how?

 

My KSP Infos:

• KSPx64 DX11
• DirectX 11-12 Fix
• TexturesUnlimited-1.1.0.12
• TexturesUnlimited_Stock.cfg

 

@Shadowmage This only occurs when you swing your view around at certain angles. The fuselage is using the stock shader and the flag is excludeMesh (so is using ksp shader). When you hit just the right camera angle, anywhere that the flag had alpha/transparency, the fuselage also disappears. This does not occur when the fuselage is using a ksp shader. It may not be easy to figure out though, as it feels a bit like a z-fighting issues between the flag and the fuselage. Does the stock shader have any kind of transparency code in it (perhaps for that opacity parameter)?