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

[ItsJustLuci]

super not keen on how any of this works, but would it be possible to get this up and running on b9 procedural wings?

oh wait nvm ignore this

Edited November 16, 2019 by lk00david

[Shadowmage]

Working on an official KSP 1.8 update, which should be available before the end of the weekend. 

Likely won't be many functional changes in the code, just a clean up and recompile for ensured compatibility.  What likely will change is that TU will only handle icon-shader replacement for TU-specific shaders; the only reason it handled stock shaders previously were the stock-DX11 compatibility issues.

I have not heard anything back from SQUAD about the 'fixes' that were mentioned regarding icon shaders for non-KSP shaders in 1.8; I cannot see any fixes in the current behavior of the program, nor have I so far been able to locate any potential API changes that would allow for mod control over icon shaders.

 

[Pedrobg]

Hello, I have seen in a mod that you could use some help modeling some stuff. I don't know where to answer it so it goes here (:

https://sketchfab.com/3d-models/badass-kerbonauts-2e81bba241e54367be784b47b066fff7

Theres more in the profile...

Contact me if you are interested.

[Idontevenkno]

When will SSTU 1.8 be coming out, I think its a great mod and want to use it in 1.8.

[Gargamel]

1 hour ago, Idontevenkno said:

When will SSTU 1.8 be coming out, I think its a great mod and want to use it in 1.8.

 

On 12/6/2019 at 3:09 PM, Shadowmage said:

Working on an official KSP 1.8 update, which should be available before the end of the weekend. 

Likely won't be many functional changes in the code, just a clean up and recompile for ensured compatibility.  What likely will change is that TU will only handle icon-shader replacement for TU-specific shaders; the only reason it handled stock shaders previously were the stock-DX11 compatibility issues.

I have not heard anything back from SQUAD about the 'fixes' that were mentioned regarding icon shaders for non-KSP shaders in 1.8; I cannot see any fixes in the current behavior of the program, nor have I so far been able to locate any potential API changes that would allow for mod control over icon shaders.

 

Literally 2 posts above yours.  

[DarkNounours]

On 12/6/2019 at 9:09 PM, Shadowmage said:

Working on an official KSP 1.8 update, which should be available before the end of the weekend. 

Likely won't be many functional changes in the code, just a clean up and recompile for ensured compatibility.  What likely will change is that TU will only handle icon-shader replacement for TU-specific shaders; the only reason it handled stock shaders previously were the stock-DX11 compatibility issues.

I have not heard anything back from SQUAD about the 'fixes' that were mentioned regarding icon shaders for non-KSP shaders in 1.8; I cannot see any fixes in the current behavior of the program, nor have I so far been able to locate any potential API changes that would allow for mod control over icon shaders.

 

This is great news, thanks for your involvement in the community!

[Shadowmage]

Unfortunately there were some complications with the shader recompiles -- trying to track down an issue with a few of the stock part-models and UV mapping, as can be seen reported here:

I have some thoughts and potential suspects to investigate as to what could be the cause; but it is slow work due to the long test cycle needed.  Hoping to catch a break and find the cause sooner rather than later, but so far the cause has eluded me.  That is really the only issue preventing a recompile and release that I'm aware of currently, so as soon as I can get it sorted out, a release should follow shortly after.  (There are some additional non-development tasks needed for this update as well, mostly wiki updates and documentation cleanup/updates, but obviously the code side stuff needs to be fixed first)

 

[Shadowmage]

After further investigation of the reported problem, it appears to be limited to some use of specific icon shaders, and possibly tied in with the KS3P enhancements.  Turning into a nice little mystery to investigate.

If I cannot definitively locate the issue within the next few days, I'll likely package up a release as-is.  The reported problems should not impact the majority of uses of the mod, and there is little reason for them to prevent further updates.

[Idontevenkno]

On 12/11/2019 at 12:10 AM, Gargamel said:

 

Literally 2 posts above yours.  

I saw that but I didnt know if it was last weekend or this weekend

[Shadowmage]

12 hours ago, Idontevenkno said:

I saw that but I didnt know if it was last weekend or this weekend

Its 'whenever I get the time in my busy life to spend some time modding on a game that I haven't actually been able to play in ~9 months'.  Could be this weekend, could be sometime next year.  It'll be out when its out.

Basically right now I'm working on tracking down some long standing mysteries with regards to external mod interaction, and cleaning up a few edge cases on material handling.  This is slow work -- long cycles of adding some debug statements, relaunching KSP, and waiting ~5 minutes for it to boot up, just to read through a log file for another ~10 minutes to look of oddities.  Worse yet is when I actually need to make changes to shaders -- those take about ~25 minutes to recompile in Unity, another few minutes to package up and update the in-use version, and then still longer for KSP to start up.

 

The other side of all this is -- the current/previous/published versions appears to work in 1.8, so nothing is stopping you from using it (which is also why I'm not in any huge rush to do a release; if it isn't broke, no need to 'fix' it).

[Vandest]

Yes it's a work that takes time, mostly with KSP.

You right, take your time to make a polished mod like you know how to do it.

Thank you to spend your time on it, and for your motivation.

[mcwaffles2003]

On 12/12/2019 at 9:18 PM, Idontevenkno said:

I saw that but I didnt know if it was last weekend or this weekend

There is literally a time/date telling you when he posted. Also, please don't pester modders, it's rude, these people work hard to make games more awesome for us to all enjoy... for free.

When you're working on something difficult how does it feel to have people around you going "Is it done yet?" "When will it be done?"

>.>

[StoneWolfPC]

On 12/13/2019 at 9:20 AM, Shadowmage said:

Its 'whenever I get the time in my busy life to spend some time modding on a game that I haven't actually been able to play in ~9 months'.  Could be this weekend, could be sometime next year.  It'll be out when its out.

Basically right now I'm working on tracking down some long standing mysteries with regards to external mod interaction, and cleaning up a few edge cases on material handling.  This is slow work -- long cycles of adding some debug statements, relaunching KSP, and waiting ~5 minutes for it to boot up, just to read through a log file for another ~10 minutes to look of oddities.  Worse yet is when I actually need to make changes to shaders -- those take about ~25 minutes to recompile in Unity, another few minutes to package up and update the in-use version, and then still longer for KSP to start up.

 

The other side of all this is -- the current/previous/published versions appears to work in 1.8, so nothing is stopping you from using it (which is also why I'm not in any huge rush to do a release; if it isn't broke, no need to 'fix' it).

This is why people like you are hero's to people like me.  I'm hoping to learn how to code and stuff eventually, but for now.......... I'm just grateful to have the chance to play this awesome game with mods awesome people like you have made.  I love how this mod makes some things look.  It's too bad more of the mods I use don't integrate it because the look is absolutely stunning.

[mcwaffles2003]

Is the mod compatible with other mods that renovate craft models like ReStock?

Edited December 21, 2019 by mcwaffles2003

[Delay]

Is it possible that  _Smoothness is handled differently to a smoothness value given in a texture?

One grayscale value I commonly use for the alphas is 85 (out of 100). That value is barely reflective, but has very bright 'hot spots'.
However, the _Smoothness float 0.85 is still very reflective. I get that kind of reflection with an alpha closer to 90 or 95.

My theory is that _Smoothness falls off linearly while the smoothness controlled by the alpha is falling off in some other way, perhaps exponential or in some kind of inverse proportionality.
Reflectivity is very rapidly lost and there is a much bigger difference between 100 and 95 than between 85 and 80.

[Idontevenkno]

On 12/16/2019 at 1:19 PM, mcwaffles2003 said:

There is literally a time/date telling you when he posted. Also, please don't pester modders, it's rude, these people work hard to make games more awesome for us to all enjoy... for free.

When you're working on something difficult how does it feel to have people around you going "Is it done yet?" "When will it be done?"

>.>

Hey just to be clear I wasn't trying to pester the dev, I was asking a question and if you read my original question for when it is out I said that I thought it was a great mod and had no problem with it. I was curious to see if there would also be new additions so If you want to be hostile to someone asking a question then please take it somewhere else then where some people want to get support to use this fantastic mod or ask questions on future content. Also the reason I started asking the developer some questions it is because I had a problem with the textures in the VAB and wanted to know if there were any mods that would result in this. I apologize to the the dev and anyone else on this forum for this and hope we can move past it. 

Edited December 23, 2019 by Idontevenkno

[Delay]

I have a problem: excludeMesh doesn't seem to be working here for some reason. It works on every mesh sans the solar panels so far.
Here's my code:
 

KSP_TEXTURE_SET
{
	name = SolarPanels
	MATERIAL
	{
		shader = TU/Metallic
		PROPERTY
		{
			name = _Metal
			float = 0.7
		}
		excludeMesh = Base.001		//Model A
		excludeMesh = Door1.001
		excludeMesh = Door2.001
		excludeMesh = Base.005		//Model B
		excludeMesh = Door1.003
		excludeMesh = Door2.003
		texture = _MainTex, VenStockRevamp/Squad/Parts/Electrical/SolarPanels/SolarPanels_CLR
		texture = _MetallicGlossMap, TexturesUnlimited_VSR/Textures/Electrical/SolarPanels_SPC
	}
	MATERIAL
	{
		shader = TU/Metallic
		PROPERTY
		{
			name = _Metal
			float = 0.7
		}
		mesh = Base.001
		mesh = Door1.001
		mesh = Door2.001
		mesh = Base.005
		mesh = Door1.003
		mesh = Door2.003
		texture = _MainTex, VenStockRevamp/Squad/Parts/Electrical/SolarPanels/Case_CLR
		//texture = _MetallicGlossMap, TexturesUnlimited_VSR/Textures/Electrical/SolarPanels_SPC
	}
}

@PART[solarPanels1|solarPanels2|solarPanels3|solarPanels4|1x3WPanels|1x3SPanels]:FOR[TU_VSR]:NEEDS[VenStockRevamp]
{
	MODULE
	{
		name = KSPTextureSwitch
		textureSet = SolarPanels
	}
}

I'm excluding these meshes because they use a different texture than the rest of the solar panels. I'm grouping all solar panels together since they are all on the same map and then exclude whatever requires a different setup, which has worked well so far.

However, the meshes (the boxes that the panels are packed in) are still patched with the upper material:

I've repeatedly checked for typos in the mesh names, but they are error-free.

[Stone Blue]

2 hours ago, Delay said:

I've repeatedly checked for typos in the mesh names, but they are error-free.

Just pulling out the shotgun here, as I dont know much at all about how TU works or PBR...

Are you replacing with your *own* textures?
Are they in .dds format?

Could the texture(s) youre trying to use have been forgotten to be flipped vertically in a conversion to .dds at some point? ... vOv

[Delay]

23 minutes ago, Stone Blue said:

Are you replacing with your *own* textures?
Are they in .dds format?

Could the texture(s) youre trying to use have been forgotten to be flipped vertically in a conversion to .dds at some point? ... vOv

Currently I'm trying to have Ven's solar panels get along with TU texture sets. The boxes use a different texture (Case_CLR) to the main meshes of the panels (SolarPanels_CLR). That's why there are two MATERIAL{} sections with "excludeMesh = "/"mesh = ": One to handle the panels themselves and one to handle the casings.
The _SPC is my own, to make actual use of TU's features. These meshes have way too many materials (as in: they emulate so many), so I cannot use constants.

The problem I have is that excludeMesh is not working. I can think of three reasons it couldn't work:
1. I made a typo in the mesh names (I literally copy-pasted the names from Blender)
2. I made a typo in the command name (Same thing here, except I copied from previous configs)
3. The command is broken (very unlikely and it has worked without problems in the past)

Edited February 8, 2020 by Delay

[Shadowmage]

On 2/8/2020 at 9:47 AM, Delay said:

Currently I'm trying to have Ven's solar panels get along with TU texture sets. The boxes use a different texture (Case_CLR) to the main meshes of the panels (SolarPanels_CLR). That's why there are two MATERIAL{} sections with "excludeMesh = "/"mesh = ": One to handle the panels themselves and one to handle the casings.
The _SPC is my own, to make actual use of TU's features. These meshes have way too many materials (as in: they emulate so many), so I cannot use constants.

The problem I have is that excludeMesh is not working. I can think of three reasons it couldn't work:
1. I made a typo in the mesh names (I literally copy-pasted the names from Blender)
2. I made a typo in the command name (Same thing here, except I copied from previous configs)
3. The command is broken (very unlikely and it has worked without problems in the past)

excludeMesh = Base.001		//Model A

I think that the inline comment might be effecting this?  I personally haven't tried those.

Other than that, it should be working like you have it configured; exclude the mesh from one config, and include it in another.  If it isn't actually excluding it, then your list of suspects is pretty much it; typos, or bugs.  As the command seems to work well most other places, it would have to be a weird/complex bug for that to be the cause.

[Shadowmage]

Updated release is available for KSP 1.8 compatibility; also fixes a few icon-shader related issues.

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

See the link for full change-log and downloads.

[Delay]

@Shadowmage I solved it. It was the mesh names.

I don't know what exactly was at fault, but I tried to remove the .00x from each mesh. Now it's working perfectly, so I'd say that the Blender exporter was at fault for - for whatever reason - giving me wrong mesh names. I don't understand why - these suffixes are important in a lot of other meshes, but here they're not?

Very clearly this mesh is called "Base.001".
But anyhow, the problem is solved. Not a bug in TU after all!

[Shadowmage]

3 hours ago, Delay said:

Very clearly this mesh is called "Base.001".
But anyhow, the problem is solved. Not a bug in TU after all!

Oh, yeah.  That is something you should be aware of when using the Blender Importer.

Blender does not support duplicate transform names, period.  So if a model has duplicate transform names, they will be renamed with the .00X suffix when imported into blender.  You should always get the transform names from in-game, using a tool like DebugStuff -- that way you know you are getting the exact names as loaded by Unity (which are the same names that TU would see).

Glad you got it sorted out though

Quote

Blender exporter

Is there a new in-KSP tool for exporting models for Blender, or were you referring to the blender import plugin?

 

Is that the newer version of Blender that I see you using, with actual in-viewport PBR shading support?  Been quite awhile since I've kept up with their updates, but I heard they were working on bringing it up-to-speed for use with modern rendering techniques.  How is it working out for you?

 

[Delay]

2 minutes ago, Shadowmage said:

Is there a new in-KSP tool for exporting models for Blender, or were you referring to the blender import plugin?

Yeah, my bad, I meant the Blender importer. The importer also an an exporter as well apparently, but I don't use it and I don't even know if it works anymore, between updated KSP and Blender releases I'm sure something broke. The Craft import got borked as well by something or it never worked in the first place.

This is Blender 2.8, with the developer shaders set in the Eevee renderer (replaced the Blender Render and it's game engine equivalent). This renderer is faster than Cycles at the expense of simpler computations and less realism, but I mainly use it to see the textures that are applied so I can judge the material I should aim for.
It looks nice as well, certainly nicer than just one gray object.

[Shadowmage]

Just now, Delay said:

Yeah, my bad, I meant the Blender importer. The importer also an an exporter as well apparently, but I don't use it and I don't even know if it works anymore, between updated KSP and Blender releases I'm sure something broke. The Craft import got borked as well by something or it never worked in the first place.

Ahh, yeah.  The import/export plugin was never fully finished; always has been some issues with it.  But it is great for what I use it for, and is far better than the alternative (nothing).

 

3 minutes ago, Delay said:

This is Blender 2.8, with the developer shaders set in the Eevee renderer (replaced the Blender Render and it's game engine equivalent). This renderer is faster than Cycles at the expense of simpler computations and less realism, but I mainly use it to see the textures that are applied so I can judge the material I should aim for.
It looks nice as well, certainly nicer than just one gray object.

Good to know; might have to d/l some recent versions and give it a spin.  Been working with 2.7.X so long...  Would be really good to be able to set up and preview some PBR materials from within Blender, without having to resort to setting up the whole Substance pipeline.