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

[Electrocutor]

@Shadowmage When you get a moment, would you mind adding the cfg syntax to the github wiki for specifying a custom color group for the recolor GUI?

I think I garnered what was needed by looking at the code for definition, but didn't see anywhere to specify the group name to use (like in the GUI PartModule).

 

KSP_COLOR_PRESET {
	name = A
	title =
	color =
	specular = 
	metallic = 
}

KSP_COLOR_PRESET {
	name = B
	title =
	color =
	specular = 
	metallic = 
}

KSP_COLOR_PRESET {
	name = C
	title =
	color =
	specular = 
	metallic = 
}

PRESET_COLOR_GROUP {
	name = MyColorPresets

	color = A
	color = B
	color = C
}

 

On 10/27/2019 at 12:46 PM, Delay said:

Is it possible to reuse parts of a textureSet for different variants?
Right now I'm redefining the same things over and over again because one thing is different for each variant. That's not only annoying because if I change one thing I have to change it everywhere, it also blows up file length and makes things less readable.

Ven's uses part variants to make different attachment sizes possible. The Ant (what I'm patching right now) can fit onto size 0 and size 1 this way, and it would be nice if I could use the same code for the nozzle without having to rewrite it.

 

Edit: Okay, in this case I can handle everything through just one material. The adapter is only enabled in on of them anyways.
Edit2: No I cannot. The textures for the  adapter don't show up, instead the engine texture does. Applying separate materials to the variants solves that.

You can re-use a textureset on as many things as you want, but not parts of it. If you want everything the same, but have different mesh= or something, then utilize ModuleManager's syntax to copy/edit a generic textureset and then add the needed mesh names to it.

 

+KSP_TEXTURE_SET[templateName] {
	%name = newName
}

 

[Shadowmage]

6 hours ago, Electrocutor said:

When you get a moment, would you mind adding the cfg syntax to the github wiki for specifying a custom color group for the recolor GUI?

Yes, excellent suggestion.  Don't think I documented that one at all.

(Off the top of my head, I think the colors themselves were added to the GROUP definitions, but its been awhile, so I'll take a look to confirm, and add it all to the docs)

[AverageUser54]

I am a bit confused by how this mod works. Can the shaders be applied to any and all parts? Is there a tutorial on how to make shaders work for certain parts? Has anyone made configs for RO parts?

https://spacedock.info/mod/1841/Textures Unlimited Default Stock Config - Unofficial

This mod works for most stock parts but in RO they get renamed so they don't work anymore. Could I change the config somehow to get it to work

Edited November 2, 2019 by PatelPratham

[bcink]

23 hours ago, Prathtel said:

Can the shaders be applied to any and all parts? Is there a tutorial on how to make shaders work for certain parts? Has anyone made configs for RO parts?

Could I change the config somehow to get it to work

Yes. 

Yes, check Electrocutor's thread - he has a guides section.

And, yes.

[Electrocutor]

On 11/2/2019 at 5:50 PM, Prathtel said:

I am a bit confused by how this mod works. Can the shaders be applied to any and all parts? Is there a tutorial on how to make shaders work for certain parts? Has anyone made configs for RO parts?

https://spacedock.info/mod/1841/Textures Unlimited Default Stock Config - Unofficial

This mod works for most stock parts but in RO they get renamed so they don't work anymore. Could I change the config somehow to get it to work

The guides I have on my thread are for variants; there is some forum discussion about TU configs though. The best resource for configs is the wiki section of the github for Textures Unlimited. If you have something specific, just ask in this thread and you'll get help. For the best stock implementation, look at:
https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/

[Delbrutis]

So does anyone know what changed In 1.8+ for Open-GL GL-Core users? TU seems to be working fine in 1.8+ under DX11. But is totally broken under GL . I know there is no official 8.0 support yet "not asking" Just had not seen any comments on it in the forums? And was curious if it is a Dll Recompile issue or was there some mod braking change to GL shaders in 1.8+? 

Thank's

 

 

[Shadowmage]

On 11/6/2019 at 10:20 AM, Delbrutis said:

So does anyone know what changed In 1.8+ for Open-GL GL-Core users? TU seems to be working fine in 1.8+ under DX11. But is totally broken under GL . I know there is no official 8.0 support yet "not asking" Just had not seen any comments on it in the forums? And was curious if it is a Dll Recompile issue or was there some mod braking change to GL shaders in 1.8+? 

Thank's

 

 

Likely as not the shaders themselves need to be recompiled using the new Unity Editor version -- shader packs were historically Unity version dependent, so it is a bit surprising that they even work under DX11

The good(ish) news is that TU will be the first of my major mods to receive an update, as it is a dependency for all the rest.  The further good news is that I should have some time this weekend to start on the 1.8+ updates.  The project I was in the middle of at work has mostly wrapped up, and while that doesn't mean that I have any more free time than before, it does mean that I can devote a bit of headspace to modding again for a bit (can only hold so many programming projects in my head at a time, and lately it has all been work related stuff).

 

[Delbrutis]

Take your time. I was just surprised I had not heard anything about other people having issues. That and the fact that TU appears to be working fine under windows had me wondering if it was something more than just a shader recompile that was going to be needed? Squad has kind of a spotty record of not testing for Linux and Mac builds and leaving out or breaking major components with new releases. And 1.8.0 was a pretty big change. Thanks for all the hard work 1.8.+ is the first update I can remember since 1.3 that actually improves performance instead of making it worse. But I really miss my shiny windows.  

 

Thank's

Edited November 8, 2019 by Delbrutis

[Gordon Dry]

I tried it last night with KSP 1.8.1 and no launch parameters (so DX11).
All VAB part icons were borked so I removed it again.

[Electrocutor]

@Shadowmage Could you also please add documentation for the uvunwrap and shader loader features to the wiki?

[Delbrutis]

On 11/8/2019 at 6:18 AM, Gordon Dry said:

I tried it last night with KSP 1.8.1 and no launch parameters (so DX11).
All VAB part icons were borked so I removed it again.

I tested on my work laptop "Its my only windows machine" and I don't have access to grab a screenshot right now. But my part icons looked fine with the latest TU and KSP1.8.0 under windows 10 DX11.   I was using a clean install with my personal TU configs. But I just dropped in my config folder and I might have had Electrocutors Unofficial patch to fix the part icons So possibly it still works for 1.8.0 ?

Edited November 10, 2019 by Delbrutis

[Shadowmage]

So... the good news is that I was finally able to take a few moments to download the KSP 1.8.1 update, the newer version of the Unity Editor that will be needed, and was able to (with quite a bit of expletive-induced coercion) get the existing code to compile versus the updated KSP binaries. 

What does that mean in regards to an updated release?  Not much, but also, quite a bit.  The existing code still functions, from a linking/compiling perspective, so that means there were no large API level changes that would break things (hooray).  This was mostly evident by the fact that the old DLLs apparently continued to function under KSP 1.8, but it is always good to confirm it by linking to the new libraries (sometimes function calls may still fail if they used reflection/etc, and weren't fully linked).

Notable issues encountered with updating of the project:

• Unity 2019 has split its dependencies into a mess of .dll's.  Each of these must be referenced individually for specific features.
• .NET framework version has to be bumped up to 4.0 (from 3.5), as the newer Unity libraries are built on that framework.
• It has been a long time since I've toyed with modding, and it is going to take me a bit to figure out where I was in all of my projects and how I had configured them and their build tools

My goals for this week are:

• Finish cleanup of old Unity versions, conversion of all KSP projects to new Unity version + link to newer libraries.
• Fix up any Unity Editor scripts that I had in KSP projects that might have been broken, such as the shader packaging script(s)
• Basic recompile of TU against new KSP binaries
• Repackage of DX11 + OpenGL shaders
• Testing KSP icon-shader code, to see if all of the ugly hacks with part-icons can finally be removed (likely not, but hoping...)
• Potentially publish an update to TU sometime over the weekend.  Other mods to come as development progresses.

 

On 11/10/2019 at 8:45 AM, Electrocutor said:

@Shadowmage Could you also please add documentation for the uvunwrap and shader loader features to the wiki?

UV-Exporter -- sure.  Its just one line in the config file that enables the feature, IIRC, but as it is a potentially useful feature (even if nobody has actually made use of it yet), still would be good to have it documented.
Shader Loader -- what aspects are you desiring documentation on? (shader package creation?)

[Manwith Noname]

3 hours ago, Shadowmage said:

...(even if nobody has actually made use of it yet)...

Might be worth mentioning then that I use it all the time and yes, it's amazingly helpful. Certainly beats failing at back porting models in to Blender and trying to export UV. Not that I've done that in KSP but have tried for skinning projects in other games. Usually I end up downloading templates made by others but they can be hit and miss at times.

[Electrocutor]

15 hours ago, Shadowmage said:

UV-Exporter -- sure.  Its just one line in the config file that enables the feature, IIRC, but as it is a potentially useful feature (even if nobody has actually made use of it yet), still would be good to have it documented.
Shader Loader -- what aspects are you desiring documentation on? (shader package creation?)

I've spoken with some authors who have wanted to use custom shaders for things, but couldn't figure out how to get shaders into KSP. When I mentioned that shader import was the whole original purpose of TU, they were surprised it could even be used for that and had thought that by even just installing TU, your whole install would be infected with shiny parts (it seems someone had uploaded a 'TU config' for stock to CKAN a long time ago that is similar to one of my old example patches that just does a mesh blanket for shiny; and this is what everyone knows TU by). I think KSP attracts a lot of new artists to try their hand at modeling, and don't understand that PBR does not mean shiny metal unless you make it so. You may also want a concise summary of what TU does and doesn't do on the Wiki Home.

It's an incredibly useful tool that seems to be misunderstood frequently.

[Shadowmage]

13 hours ago, Manwith Noname said:

Might be worth mentioning then that I use it all the time and yes, it's amazingly helpful. Certainly beats failing at back porting models in to Blender and trying to export UV. Not that I've done that in KSP but have tried for skinning projects in other games. Usually I end up downloading templates made by others but they can be hit and miss at times.

Good to know.  Would have added documentation anyway, but I'm glad someone is making use of the feature, and happy that it could be helpful to someone other than myself    That was the whole intent -- could be faster than ripping the model into blender just to look at UV's.

59 minutes ago, Electrocutor said:

It's an incredibly useful tool that seems to be misunderstood frequently.

Indeed, feels like it got a bit of a bad name/rep from all of the 'make it shiny' patches floating around, and nobody bothered looking into the mod past that, or what its intended purpose was.

Glad that some further consideration is being done on the mod, for its intended uses, and I will be happy to add some documentation to support that.

1 hour ago, Electrocutor said:

and don't understand that PBR does not mean shiny metal unless you make it so.

I wish I could get that point across to more people.  PBR brings so much more to the table than metallics, but it seems not many are interested.

[Shadowmage]

On 11/10/2019 at 2:58 PM, Delbrutis said:

I tested on my work laptop "Its my only windows machine" and I don't have access to grab a screenshot right now. But my part icons looked fine with the latest TU and KSP1.8.0 under windows 10 DX11.   I was using a clean install with my personal TU configs. But I just dropped in my config folder and I might have had Electrocutors Unofficial patch to fix the part icons So possibly it still works for 1.8.0 ?

Unfortunately, my initial testing has revealed that SQUAD has not fixed the part-icons.  They are as screwed up as ever if I turn off TU's icon replacement code, at least in the default configuration.  During the pre-1.8 discussions, one of the devs mentioned that there might be some configurability regarding this, so I'm inquiring now to see if it was actually implemented.

Quite sad that the first thing I look at in the update is broken (even though I was told it would be fixed), doesn't spell good things for the rest of the update.

[Delay]

1 hour ago, Shadowmage said:

Unfortunately, my initial testing has revealed that SQUAD has not fixed the part-icons

What does it look like without TU? Since d3d9 is now dropped, part icons must work in d3d11, so it's possible TU is actually at fault.

[Shadowmage]

2 minutes ago, Delay said:

What does it look like without TU? Since d3d9 is now dropped, part icons must work in d3d11, so it's possible TU is actually at fault.

Icons for parts using KSP/XXXXX shaders work fine.  Icons using any non-KSP/XXX shaders (e.g. any TU shader) revert to using the default icon-shader for legacy-diffuse textures.  For this test I manually disabled all TU icon-related features (by removing the icon-shader configs that drive the icon-shader replacement), as I was intentionally testing the stock icon-shader handling.

Here is how KSP 'handles' non-KSP shaders (e.g. TU/Metallic, etc):

More ugly bits...

They aren't un-textured -- they are fully textured, but are using the legacy diffuse shader, which renders PBR textures very poorly.

Quite the mess.  Finding it really hard to care past this point.  Regardless, I don't think I'm carrying the part-icon manipulation code forward; I was told this was going to be a solved problem, and I lack the motivation to continue fixing stock issues, especially when they do not provide the API level hooks to solve it properly.  I'll reconsider if I find that stock did add proper hooks, but so far I have not seen/heard anything about it.

Now, to their credit, the 'blue icons under DX11' issue has been fixed, but as DX11 is the new default for Windows, I would expect nothing less.

[Delay]

4 minutes ago, Shadowmage said:

Icons using any non-KSP/XXX shaders (e.g. any TU shader) revert to using the default icon-shader for legacy-diffuse textures.

Is it not possible to set the shader for the parts list back to KSP/...?

Edited November 12, 2019 by Delay

[Shadowmage]

3 minutes ago, Delay said:

Is it not possible to set the shader for the parts list back to KSP/...?

I'm not understanding the post? 

The icons in the parts list -are- using KSP icon-shaders (specifically KSP/ScreenSpaceMask(sp?)) -- that is the entire problem.  They should be using some PBR-featured icon shader, and should show reflections/etc.  Edit:  Even if I were to somehow be able to do this -- the issue is that the KSP/XXX icon shaders don't render PBR textures properly (no reflections, no smoothness, no bump-maps, no AO maps, etc).

(The TU replacement icon shaders do still work when their configs are enabled, and both render the textures and show reflections properly; however I was told these icon-related hacks should no longer be needed, which is what I was testing)

Edited November 12, 2019 by Shadowmage

[Delay]

Just now, Shadowmage said:

The icons in the parts list -are- using KSP icon-shaders (specifically KSP/ScreenSpaceMask(sp?)) -- that is the entire problem.

Oh sorry, didn't see that. Parts don't look like that in the stock part list, so I thought you meant some sort of fallback shader.

[Shadowmage]

Just now, Delay said:

Oh sorry, didn't see that. Parts don't look like that in the stock part list, so I thought you meant some sort of fallback shader.

Yeah, the stock parts that use stock shaders look fine in the parts list.  Its only parts using non-KSP PBR-based shaders that have messed up icons (legacy non-KSP shaders should still work fine).

[Delay]

@Shadowmage Here's a case of TU not playing well with Scatterer: Atmospheres show up behind other celestials in reflections. Nothing overly major.

[Shadowmage]

13 minutes ago, Delay said:

@Shadowmage Here's a case of TU not playing well with Scatterer: Atmospheres show up behind other celestials in reflections. Nothing overly major.

Nothing I can do about it (edit:  maybe I could, but I'm not going to).  Its a problem between Scatterer and Unity's reflection probes.  The same issue will show up (without TU installed) if using any stock parts with reflections with scatterer in use.  (if that is somehow not true, please let me know; but at this point TU does nothing with reflection generation, and it only interaction is to set the shaders/materials on the part models)

Prior to stock implementing reflection probes (KSP 1.6), I had a big and nasty complicated set of hacks and workarounds to get Scatterer (and EVE) to show up properly in reflections.  Now that stock has added reflection probes (KSP 1.7?) -- it is no longer my problem (now the burden to fix the issue is with the other mods adding the features + their interaction with the stock features).  Hate to pass-the-buck, as it were, but I can't fix others' code

Edited November 15, 2019 by Shadowmage

[Manwith Noname]

It might even be a stock issue. Zooming in I can definitely see clouds and possibly land beneath the haze. Would be interesting to see if Kerbin shows without scatterer or E.V.E installed.

 

Edit:

It is a stock problem. Modified the rover probe core shininess and dumped it in a low lunar orbit, you can see Kerbin.

Edited November 16, 2019 by Manwith Noname