Shadowmage

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

Recommended Posts

On 9/6/2019 at 8:02 PM, claustro said:

Given that KSP 1.8 is around the corner, with native DX11 support, using Unity 2019.2, will that deprecate your mod or just make your life harder, Shadowmage, to change all the code to be once again compatible? Just wondering what it means for the code of TU and if its a sigh of relief to you (YAY, native support!) or more a sigh of "OH-NO-ALL-BROKEN!"

In reality -- shouldn't be too much changed with TU.  I'll have to recompile my shader bundles for the new Unity Player version, that is a given.  Beyond that, I might have to (hopefully) remove the code that 'fixes' the part-icons, depending upon how well that feature was fixed up (or if it was fixed up).  As TU basically already 'expected' DX11/OpenGL Core to be used, there isn't much else that should need to be changed or updated.  Certainly the change won't deprecate TU, as I doubt they've included Standard shader variants in KSP proper, and even if they did, I guarantee they aren't including the full texture-switch and recoloring systems that TU has implemented.

Shouldn't be any breakage on the config end of things either -- as far as I know at this time, nothing should really be broken by the update.

I suppose we'll find out more whenever 1.8 drops (ETA:  ~ a month from now?).

Share this post


Link to post
Share on other sites

Is it possible to add KSPTextureSwitch to specific part variants? I'm asking because MODULE{ name = KSPTextureSwitch } doesn't seem to work inside @VARIANT code.

Edited by Delay

Share this post


Link to post
Share on other sites
9 hours ago, Delay said:

Is it possible to add KSPTextureSwitch to specific part variants? I'm asking because MODULE{ name = KSPTextureSwitch } doesn't seem to work inside @VARIANT code.

PartVariants don't use the KSPTextureSwitch -- they use the TUPartVariant module, and are set up slightly differently.  See an example here:  https://github.com/shadowmage45/STUCK/blob/master/GameData/STUCK/Stock/Aero/aerodynamicNoseCone/aerodynamicNoseCone-TextureSets.cfg

Share this post


Link to post
Share on other sites
4 hours ago, Shadowmage said:

PartVariants don't use the KSPTextureSwitch -- they use the TUPartVariant module, and are set up slightly differently.

I thought that KSPTextureSwitch allowed KSP to use the TU mats in the first place. Then I'm afraid I don't quite understand what the module is for.
The question was aimed for the case of multiple texture sets for each variant. As an example I have two mats for the Mk3 parts - one more metallic and one less metallic to reflect what aircraft (reflective) and the space shuttle (barely anything reflecting) looked like.
Now, Mk3 only has one variant for each of its parts, but what if I do have a multi-variant part and I want to have a choice between different texture sets?

Edited by Delay

Share this post


Link to post
Share on other sites
6 hours ago, Delay said:

I thought that KSPTextureSwitch allowed KSP to use the TU mats in the first place. Then I'm afraid I don't quite understand what the module is for.

The texture switch module was the implementation before Squad introduced variants. It's probably still the preferred method based on my experience. The part variant module exists because of how Squad handled "GAMEOBJECTS" in their parts. There was a number of issues surrounding working with parts that Squad have introduced variants to.

6 hours ago, Delay said:

The question was aimed for the case of multiple texture sets for each variant. As an example I have two mats for the Mk3 parts - one more metallic and one less metallic to reflect what aircraft (reflective) and the space shuttle (barely anything reflecting) looked like.
Now, Mk3 only has one variant for each of its parts, but what if I do have a multi-variant part and I want to have a choice between different texture sets?

I might be misunderstanding the question but you can apply multiple variants much like you can apply multiple texture sets...

Spoiler

C56E51C5087AFC0C160A2D2B6F2E2253C9155404

The cockpits use TU texture switch and the rover parts use variants. From left to right, as can be seen in each menu, Stock shaders, metallic shaders and recolour shaders. If the rover / lander was converted to use the original texture switch module, the extra lander components would always be applied because Squad don't handle things as separate models as such. It's one "model" with meshes turned on and off via the "GAMEOBJECTS" flags. Rather than rewrite the entire system, the variant module integrates with the existing Squad system.

 

...and in posting this I've noticed something that needs fixing.

Share this post


Link to post
Share on other sites
18 hours ago, Delay said:

The question was aimed for the case of multiple texture sets for each variant.

Your thinking of it incorrectly.

You need to make a new variant per texture set that you wish to add.  When PartVariants are in use, they control the texture switching, TU just provides the shaders (and some hooks to use those shaders properly).

12 hours ago, Manwith Noname said:

The cockpits use TU texture switch and the rover parts use variants.

Yep, both serve the same purpose in the end -- to use the TU shaders.  Its just that stock made this terribly terrible 'PartVariant' system that didn't play nicely with... well... anything... so I had to come up with a special method to allow for still patching shaders/parameters while the PartVariant system was in use.

12 hours ago, Manwith Noname said:

...and in posting this I've noticed something that needs fixing.

Isn't that always the way it goes?  Set up a presentation for something, start going through it, and then its like 'oops... I guess that needs to be fixed' :)  (at least it never fails for me, no matter how many times I check over everything and test it prior).

Share this post


Link to post
Share on other sites
44 minutes ago, Shadowmage said:

Your thinking of it incorrectly.

You need to make a new variant per texture set that you wish to add.  When PartVariants are in use, they control the texture switching, TU just provides the shaders (and some hooks to use those shaders properly).

Yep, both serve the same purpose in the end -- to use the TU shaders.  Its just that stock made this terribly terrible 'PartVariant' system that didn't play nicely with... well... anything... so I had to come up with a special method to allow for still patching shaders/parameters while the PartVariant system was in use.

I think I got it now. If PartVariants is not in use I can make different texture sets and use KSPTextureSwitch, else I have to make every texture set its own variant.

Share this post


Link to post
Share on other sites
2 hours ago, Delay said:

I think I got it now. If PartVariants is not in use I can make different texture sets and use KSPTextureSwitch, else I have to make every texture set its own variant.

Pretty much.  The two systems are mutually exclusive -- you either use the Stock PartVariant system (and thus use Variants that link to a single texture-set), or you use the KSPTextureSwitch system (and directly switch between texture-sets).  They cannot work alongside eachother without issues, mostly due to the stock system stomping all over materials and settings.

They both use the same KSP_TEXTURE_SET config definition/data construct, so at least there is a bit of consistency in the mod in that regard.

Share this post


Link to post
Share on other sites

Hi there.

I am having a problem with the textures on the octosat.

When i build it, its pretty, shiny, and golden.
But the moment i am outside the VAB it turns jetblack, blacker than black. Tbh the texture becomes as lightless as a black hole. 

Have anyone encountered this problem before, and maybe know how to fix it?

Share this post


Link to post
Share on other sites
2 hours ago, Aremos said:

Hi there.

I am having a problem with the textures on the octosat.

When i build it, its pretty, shiny, and golden.
But the moment i am outside the VAB it turns jetblack, blacker than black. Tbh the texture becomes as lightless as a black hole. 

Have anyone encountered this problem before, and maybe know how to fix it?

Likely that your stock reflection settings are set to 'disabled' for real-time updates.

Go into the game options, find the settings dealing with reflection quality/speed, and enable them.  Not at a KSP enabled computer at the moment, to can't give any more specific info =\

Share this post


Link to post
Share on other sites
18 hours ago, Shadowmage said:

Likely that your stock reflection settings are set to 'disabled' for real-time updates.

Go into the game options, find the settings dealing with reflection quality/speed, and enable them.  Not at a KSP enabled computer at the moment, to can't give any more specific info =\

I think that was it. Found out that the SSTU textures allso made som strange things, but now its nice metallic, and reflect the heavens and the earth like some mirror from space, delivered in person by the great space goblin.

 

Thanks man :)

Share this post


Link to post
Share on other sites
On 10/2/2019 at 2:38 PM, Beatbox309 said:

Is there support for part packs like ReStock? Or is it just a matter of creating a config? 

No, and yes (and creating any missing textures; e.g. the metallic maps).

Sounds simple, but it is a ton of effort to add support for mods extrenally.  TexturesUnlimited was intended to be a tool for the mod developers themselves to use as part of their workflow, where it is not quite as painful to do the setup if it is done during the model/texture creation and included in the workflow from start to finish.  But trying to come in after the fact, without the original art assets (e.g. layered texture files, substance projects, etc), is a major pain, extremely time consuming, and the result is not nearly as good as it could be had it been done properly from the start.

Unfortunately, not many mod authors showed any interest in using it, so not many mods have TU support.  SSTU is about the only one that I know of that actually makes use of it for all of its parts/textures (see signature).

Share this post


Link to post
Share on other sites
3 hours ago, Shadowmage said:

No, and yes (and creating any missing textures; e.g. the metallic maps).

Sounds simple, but it is a ton of effort to add support for mods extrenally.  TexturesUnlimited was intended to be a tool for the mod developers themselves to use as part of their workflow, where it is not quite as painful to do the setup if it is done during the model/texture creation and included in the workflow from start to finish.  But trying to come in after the fact, without the original art assets (e.g. layered texture files, substance projects, etc), is a major pain, extremely time consuming, and the result is not nearly as good as it could be had it been done properly from the start.

Unfortunately, not many mod authors showed any interest in using it, so not many mods have TU support.  SSTU is about the only one that I know of that actually makes use of it for all of its parts/textures (see signature).

Aw that's a shame, still a great mod/tool regardless though! I'll have to check out SSTU. 

Share this post


Link to post
Share on other sites

@Shadowmage with regards to the part icon fixes you made I can only say: If KSP goes dx11 (which it is) then the part icons have to work. So you can remove your code anyway since it’ll allow you to simply say “Not my problem, that’s Squad’s code”. 

Even if it’s still broken, Squad went dx11 so it’s their job to make it work. 

Share this post


Link to post
Share on other sites

Strange...

I patched the Mk 1-3 pod and now the _Emissive doesn't seem to do anything. The cockpit windows remain blue.
I made sure I typed everything in right, I even copied the file names over just to be sure!

Share this post


Link to post
Share on other sites
Posted (edited)

@Delay

You'll need to remove the alpha channel from the texture and point to your modified version. There's a few more like this on other parts but I can't remember them all off hand. Pretty sure the new MK2 lander / rover has an odd alpha layer too.

Edited by Manwith Noname

Share this post


Link to post
Share on other sites

Hello

I'm using EVE with AVP, KS3P and scatterer.

I installed TU to fix blue icons in VAB under Dx11 and for better textures overall...

But unfortunately now I got black clouds on top of white ones, KS3P totally got broke and all effects are gone.

I'm sorry if this is a known issue, but I would greatly appreciate it if someone could help me fix things up.

Share this post


Link to post
Share on other sites
20 hours ago, Smart Parts Wanter said:

Hello

I'm using EVE with AVP, KS3P and scatterer.

I installed TU to fix blue icons in VAB under Dx11 and for better textures overall...

But unfortunately now I got black clouds on top of white ones, KS3P totally got broke and all effects are gone.

I'm sorry if this is a known issue, but I would greatly appreciate it if someone could help me fix things up.

At this point I’d honestly recommend waiting on dx9 until native dx11 arrives with working icons.

Though considering my game is so modded I don’t have enough ram for dx9 I can understand that not being an option for you. :P 

Share this post


Link to post
Share on other sites
On 9/24/2019 at 12:18 PM, Shadowmage said:

Pretty much.  The two systems are mutually exclusive -- you either use the Stock PartVariant system (and thus use Variants that link to a single texture-set), or you use the KSPTextureSwitch system (and directly switch between texture-sets).  They cannot work alongside eachother without issues, mostly due to the stock system stomping all over materials and settings.

They both use the same KSP_TEXTURE_SET config definition/data construct, so at least there is a bit of consistency in the mod in that regard.

This isn't entirely true. You can use KSP_MODEL_SHADER to simply set the meshes to use the TU shader, then use ModulePartVariants to set all the textures, floats, etc on the TU shader per variant. Variants cannot change the shader and keywords is all; and if you use recoloring, you need a TU-centric PartModule to store your preferences.

Share this post


Link to post
Share on other sites
4 hours ago, Electrocutor said:

This isn't entirely true. You can use KSP_MODEL_SHADER to simply set the meshes to use the TU shader, then use ModulePartVariants to set all the textures, floats, etc on the TU shader per variant. Variants cannot change the shader and keywords is all; and if you use recoloring, you need a TU-centric PartModule to store your preferences.

While technically true, it is a bit of an advanced use, as it requires an understanding of how all of the different components work together (which is generally something only plugin authors would grasp), so I don't advertise it as a standard use scenario.  I have enough on my plate helping people figure out the 'standard' uses already :)

(With that said, yes, it is a valid technique, but as it relies upon the ModulePartVariants internal functioning, I cannot guarantee that it will continue to work for any particular use if/when SQUAD updates that module)

Share this post


Link to post
Share on other sites

First off: This mod is amazing. It's impressive just how much KSP's graphics can be enhanced by just rendering things differently.

However, there is one problem I'd like to mention. Now, I'm using Scatterer, so this may be one of the few cases where Scatterer and TU don't run well together, but the Sun is just a black circle in reflections, like this:
wihMEAS.png

Is this a case of Scatter incompatibility or a general problem of reflections?

Share this post


Link to post
Share on other sites
15 hours ago, Delay said:

First off: This mod is amazing. It's impressive just how much KSP's graphics can be enhanced by just rendering things differently.

However, there is one problem I'd like to mention. Now, I'm using Scatterer, so this may be one of the few cases where Scatterer and TU don't run well together, but the Sun is just a black circle in reflections, like this:
wihMEAS.png

Is this a case of Scatter incompatibility or a general problem of reflections?

 

That is a case of KSPs odd rendering system  (scaled space, multiple cameras) not playing nicely with Unity's Reflection Probe system.  Is something that SQUAD would have to fix, as it is a problem with their rendering systems.

TU does not handle any of the reflection mechanics anymore (it used to in the past); that is now all stock code.  All that TU does is provide the Unity-Standard compatible PBR shaders (and provide mechanisms for loading those and applying to parts/models).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.