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

[Shadowmage]

1 hour ago, Electrocutor said:

Do the mask textures need to be the same dimensions as the diffuse, or can we make a smaller mask (to save vram and decrease load) and your shader will stretch it to match the diffuse dimensions?

Any dimension, auto-scaled in the shader.  Even different aspect ratios if needed.

I've actually found that with the recoloring shader you can use much lower res diff/spec maps, but keep the mask higher res (and also keep it a .png so there is no mip-mapping).  This gives nice sharp lines between the recolored selections, and allows for some detailed use of it for painting..well, details.  The diffuse/mettallic/specular maps are all just noise/grunge, and a little blur from lower res is barely noticeable.

[Puggonaut]

13 hours ago, Shadowmage said:

That wasn't actually something I made, but was posted by @Temeter I believe.  Perhaps he might be willing to share how he set it up (tagged him, so no need for PM's).

You'll need to make sure you have the SSTU-PBR expansion installed as well, as that is what will enable the metallic-like settings.  You'll still need to open the recoloring GUI and play around with the color sliders in there.  ( https://github.com/shadowmage45/SSTULabs/releases/tag/PBR-0.1.0.4 )

Thanks got the file @Temeter uploaded and the Expansion , it works and its amazing , thanks again to both of you

EDIT

Its so shiny my Dog needed sunglasses

 

Edited November 24, 2017 by Puggonaut 2
Pic Added

[hypervelocity]

wow @Shadowmage, this looks awesome!!! 

would you consider the prospect of supporting Procedural Parts in the future?

[Shadowmage]

2 minutes ago, hypervelocity said:

would you consider the prospect of supporting Procedural Parts in the future?

I will not personally be adding support for any mods (except for those that I author/maintain).  It is up to those mods' authors to use TU or not.  (or for some third-party to integrate the two)  This is why I have released it as an 'API' and not a giant 'conversion' mod.  (API = framework for others to make use of, providing convenience and support of the underlying technical aspects)

In the case of PP -- the support would almost certainly have to be built into PP at the plugin level.  As there majority of this API is intended to work on .mu models, applying them to the PP parts could be more complicated than standard models.  There should be nothing preventing PP from using the TU shaders, but it would certainly take some effort to get it all working.

So your best bet would be to ask in the PP thread if they intend on supporting the PBR/Standard shaders.  They are the only ones who will be able to answer the question.

[hypervelocity]

thanks for the detailed explanation!!!

[Agustin]

13 hours ago, hypervelocity said:

wow @Shadowmage, this looks awesome!!! 

would you consider the prospect of supporting Procedural Parts in the future?

Hola Hypervelocity. have you installed SSTU? i have installed it recently and found that it is really a much better "procedural" parts mod than procedural parts which i find toos  simple. SSTU comes with so many tweaks you can do on a part and besides you can configure its textures to so beautiful things...  But apart from that, it really is like a proecdural tank, engines parts and it has some really nice command pods....

[vossiewulf]

3 hours ago, Agustin said:

Hola Hypervelocity. have you installed SSTU? i have installed it recently and found that it is really a much better "procedural" parts mod than procedural parts which i find toos  simple. SSTU comes with so many tweaks you can do on a part and besides you can configure its textures to so beautiful things...  But apart from that, it really is like a proecdural tank, engines parts and it has some really nice command pods....

Both have their place. For example PP tanks vary dynamically vs. .5m increments like SSTU, so vehicles where you need to control the tank size very finely (most likely with small probes) PP tanks are useful. Also I never look through all the cone-shaped tanks trying to find ones with the right end dimensions, I make those from PP tanks also. And if you're using a non-SSTU pod, PP batteries are always the way to go. Most things I make are predominantly a mix of SSTU and PP.

[gmiddlemass]

@ShadowmageJust saw that you were featured on "Star Mods" congratulations. Hopefully the extra attention will get a few more people using these awesome textures

[Puggonaut]

So does anyone know of a mod that i can muck about to get nice shiny wings ??? or does any of the mods you allready make allow to do it @Shadowmage

As you can see i'm sort of 1950-60's influenced in some of my more wacky idea's

Edited November 25, 2017 by Puggonaut 2

[Shadowmage]

3 hours ago, Puggonaut said:

or does any of the mods you allready make allow to do it

Not that I'm aware of, sorry -- I stay away from aero stuff due to part-count-bloat.  There is a stock-conversion patch floating around the thread somewhere, but I don't think it makes the wings metallic.

Since you already have TU installed, you could try doing the conversion yourself -- lots of free resources available that can make textures, and once you have the textures TU can be used to put them on the parts.

 

8 hours ago, gmiddlemass said:

@ShadowmageJust saw that you were featured on "Star Mods" congratulations. Hopefully the extra attention will get a few more people using these awesome textures

Thanks    Yep, certainly seen a few more people stopping by.  The real trick will be getting other modders on board with it, as those are the ones who would have to do the actual work.

[Puggonaut]

37 minutes ago, Shadowmage said:

Not that I'm aware of, sorry -- I stay away from aero stuff due to part-count-bloat.  There is a stock-conversion patch floating around the thread somewhere, but I don't think it makes the wings metallic.

Since you already have TU installed, you could try doing the conversion yourself -- lots of free resources available that can make textures, and once you have the textures TU can be used to put them on the parts.

 

Thanks    Yep, certainly seen a few more people stopping by.  The real trick will be getting other modders on board with it, as those are the ones who would have to do the actual work.

Aha okidoki so can you or someone explain , in very small words how I would do that ?

Once again thanks for your prompt reply .

[Agustin]

The function of this vessel is to provide a glimpse with what I've been playing around, picking the colors, so that people can understand the scope of this. And it's a beauty... Choose texture, color, metallic component, specular, holy Kod....
(It is not very high definition though, but maybe you can post more images.. as my computer isn't that great but stills doesn't losses performance with this installed so....

Edited November 25, 2017 by Agustin

[gmiddlemass]

Just noticed that the Electron and New Glenn mod by Superpenguin 160 is using these shaders now too.

And so it begins...

[Shadowmage]

Updated release is available:

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

Quite a few fixes to reflection probe handling -- stock atmospheres should no longer disappear, launch-clamps should no longer cause reflection problems once in-orbit, and the skybox is captured in reflections while in the editor (VAB/SPH).  Should be fully backwards compatible with existing releases.

@HebaruSan  This release moves the mod out of pre-release status, so should be indexable by CKAN.  Poke me if there is anything else I need to setup.

 

12 minutes ago, Puggonaut said:

Aha okidoki so can you or someone explain , in very small words how I would do that ?

Once again thanks for your prompt reply .

Teaching how to make textures is a bit out of my area, and not really something that can be explained briefly.  Check out the 'modeling and texturing' sub-forum as there is a lot of information and a few tutorials available there.

[HebaruSan]

16 minutes ago, Shadowmage said:

This release moves the mod out of pre-release status, so should be indexable by CKAN.  Poke me if there is anything else I need to setup.

Should be good to go now. Thanks for the heads-up!

[Agustin]

4 hours ago, Shadowmage said:

Updated release is available:

https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.0.0.4@HebaruSan

 

Can you upload to a different website too? It's not working for me that link don't know why...

Never mind,,, changed y internet connection and worked....

Edited November 26, 2017 by Agustin

[Pol]

Can you enlighten me on pbr sss Thickness map. it's just value of color or how it work? I sort of make it work but I prefer understanding and with my restaring times experimenting takes eternity/

 

 

by the way the short video of my test platform and result of my experimenting with it 

Spoiler

 

 

Edited November 26, 2017 by Pol

[Temeter]

16 hours ago, Puggonaut said:

So does anyone know of a mod that i can muck about to get nice shiny wings ??? or does any of the mods you allready make allow to do it @Shadowmage

 

Spoiler

 

As you can see i'm sort of 1950-60's influenced in some of my more wacky idea's

Your best bet is B9 procedural wings. Obviously no PBR shaders, but you can change the wings color and have some surfaces:

Also, that's a neat rocket

 

[Bonus Eventus]

@Shadowmage great job man, this is awesome

[Shadowmage]

11 hours ago, Pol said:

Can you enlighten me on pbr sss Thickness map. it's just value of color or how it work? I sort of make it work but I prefer understanding and with my restaring times experimenting takes eternity/

 

 

by the way the short video of my test platform and result of my experimenting with it 

  Hide contents

 

 

Pro-tip -- drop these files:  https://github.com/shadowmage45/TexturesUnlimited/tree/master/CustomShaders   into your Unity Editor Assets folder somewhere, and the shaders will show up in Unity for you to play around with.  No more having to relaunch KSP to test simple changes.

The _Thickness map is an RGB texture that determines both how 'thick' the mesh is in that spot, as well as giving an optional 'color' to the light that bleeds through.  There are 5 other sub-surface related parameters that also influence how the lighting works.  Best bet is to play around in Unity Editor.

The SSS shader is entirely based on this work, pretty much down to using almost the exact same code.  A read through those articles will probably explain what the features are better than I can.

https://www.alanzucconi.com/2017/08/30/fast-subsurface-scattering-1/

https://www.alanzucconi.com/2017/08/30/fast-subsurface-scattering-2/

 

An in-use example would be the SSTU-ISS solar panel parts/textures: 

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

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

The 'GLOW' is what I'm using for _Thickness.  Linked the DIFF just for reference.

[Shadowmage]

@Electrocutor

I've got some code and updated in testing that should allow for use of the 'masked' recoloring shader to be applied to standard parts/textures as a tinting shader.  It will still require the 'mask' texture to determine which of the 3 'sections' are applied to what portions of the mesh, but it should be usable with existing part DIFF textures.

I'm also experimenting with shader-keyword support.  Apparently part of the problem I was running into was due to Unity's use of SHADER_FEATURE rather than MULTI_COMPILE in its 'Standard' shader implementation (which was causing the sub-variants to not be included).  When using MULTI_COMPILE, all variants are included in the build, even if not used/referenced -- which is exactly the behavior that I need.

So far the only thing using the feature will be the masked/recoloring shaders.  I might add the feature to NRM and/or GLOW texture slots in the future for a tiny bit of optimization.... but will need to find out how the material is handled when just the shader is swapped out (are the keywords reset when changing shaders?).

I'm also hoping to get the 'UV Map Exporter' working properly so that you might be able to dump/export UV-maps for all of the stock parts, to facilitate the creation of proper mask textures for recoloring.

[Electrocutor]

From most feedback I've gotten, the only reason people like using the stock cfg is mostly because it does not use additional maps (which requires additional vram, more hdd access, etc). The reason why they like it is because it effectively loses no frame-rate, but still achieves improved visuals. The people who don't mind using additional vram usually use Vens or other stock part replacement models/textures.

Currently, my solution is to just have a 1 pixel red, blue, and green texture that can be assigned as _MaskTex. Honestly, it'd be nice if you created a list of generator texture names, such "white", "black", "gray", "bump", "metal", "red", "green", and "blue" that would auto-generate a single pixel texture.

shader = SSTU/PBR/Masked
mesh = fueltank
texture = _MaskTex,red

 

The shader keyword support sounds fun; if you can access them within ShaderLab, that'd give you more freedom to do interesting things without having to create additional shaders with tiny differences between them: for example, a cfg option of whether or not a diffuse texture is desaturated before applying the _Color1 blend (a GUI option), the ability to make procedural textures, etc.

I had once changed all the Standard shader ginc to be MULTI_COMPILE and then offloaded the result into an asset bundle. Unfortunately, I could not get them to load into KSP: not sure if it was an issue in code or if it just doesn't like have the Standard shader names being imported like that.

----

Some things I've found while tinkering:

• The PBR Masked shader has issues with overloading the metallic and smoothness numbers (perhaps others as well that I just didn't notice). I've not had time to narrow down the cause, but the result is that 100% metallic and smoothness is achieved by setting the GUI to 127 instead of 255. I imagine this is some combination of color and alpha values of the various maps.
   
• The reflection probe has the age-old same problem as the TRReflection probe: it blocks the GUI and physics thread too long, which causes a micro-stutter every time the reflection surface textures update. This is not an issue when using a Unity default reflection probe even when set to update in real-time with all 6 faces; so some efficiency work likely needs done on the spaghetti code that is needed to show everything in reflections. My guess is that simply employing coroutines would likely alleviate the problem for the time being until a more efficient method can be devised.

[Shadowmage]

5 hours ago, Electrocutor said:

The PBR Masked shader has issues with overloading the metallic and smoothness numbers (perhaps others as well that I just didn't notice). I've not had time to narrow down the cause, but the result is that 100% metallic and smoothness is achieved by setting the GUI to 127 instead of 255. I imagine this is some combination of color and alpha values of the various maps.

Yes, I've stated the reason for this a few times; it is not a 'tinting' shader, it is a 'recoloring' shader that expects the base input texture to be flat gray.  If you are using a white (or default=none) for textures, then it can over-saturate everything depending on UI inputs.  Your DIFF/SPEC/MET textures -MUST- be 128,128,128 with minor details added as highlights/shadows (e.g. refer to the DIFF image that I posted with the MASK texture).  You can see from the pics of people using the recoloring shader in SSTU that it works just fine -- as long as you give it the texture inputs that it expects.

The next release will include an option/parameter/keyword that will toggle this shader to 'tinting' mode, where it will perform probably more like you expect (baseTextureColor * userColor).  Currently it is (baseTextureColor - 0.5 + userColor).

 

5 hours ago, Electrocutor said:

The reflection probe has the age-old same problem as the TRReflection probe: it blocks the GUI and physics thread too long, which causes a micro-stutter every time the reflection surface textures update.

This is because of how the scene has to be rendered.  Are you versed with KSP's non-standard rendering setup (multi-camera, layered scene, different scaling)?  Not really anything that can be done about it from the modding end.  You would have to talk to SQUAD and tell them to use a standard camera setup (good luck... won't work due to the scales used in KSP, even just on Kerbin... Unity was never meant to have more than a ~2km map area).

There is no way to avoid rendering the scene ~24 times.  4 layered passes for each of the 6 cubemap faces.  Unity's render-probe doesn't have to do this (it only renders each face once), but it is this lack of layered rendering support that is the entire reason TU exists (if the reflection probes 'just worked'... there would be no need for this mod).  Now, to make it worse, in order to get the image actually into the reflection probe, not only do I have to render the scene, but then the reflection probe needs to capture it from inside of a an object setup just for that purpose (can't use the cubemap that TU rendered directly, as it needs specular convolution applied, and Unity hasn't given access to those shaders/code).  So all told, the scene is getting rendered 30 times just to update the reflection probe once.

Currently I'm breaking this up and rendering each face of the cube on one frame (4 passes per frame/face), and after all faces have been rendered (6 frames), I pass it off to the reflection cube.  It then renders one-face-per-frame for the next 6 frames, and finally, for 8 more frames after that, it blurs one MIP level per frame.  So the total update time for each 'reflection update' is already spread across 20 frames from start until finish.

Literally the only thing that could be done to improve this further, would be to break up the per-face rendering to also split up the layered rendering.  Render only one-layer of one face per frame, so the TU updates would stretch out to 24 frames, + another 14 for the reflection probes internal updates.

Edit:  Feel free to submit a PR if you are that interested, or that effected -- my personal motivation to fix what is not a problem for me, is expectedly low.

(using co-routines will not solve anything here, all that could possibly do is shift -when- the updates occur, it is not going to miraculously make them faster or cheaper)
(I've also not had any problems with stutter/micro-stutter -- I seem to get a nice and smooth 60fps out of it on my machine; even examination with FRAPs exposes only rare stalled frames)

Edit:  @ElectrocutorI have thought of one thing that might be done to increase performance in places where multiple vessels are active/loaded -- Currently there is one reflection probe per-vessel, but with how things are setup, there would be little/no visible difference if there was only a single reflection probe in the entire scene that was positioned for the actively controlled vessel.

I had briefly toyed around with this concept when trying to track down the collider-explosion problems, and even refactored the code for it, but ended up finding the solution to that problem elsewhere so never merged in the changed branch.  Will see what I can do to get this included for the next release, even if only as a config-based toggle.

 

 

Edited November 28, 2017 by Shadowmage

[Shadowmage]

5 hours ago, Electrocutor said:

From most feedback I've gotten, the only reason people like using the stock cfg is mostly because it does not use additional maps (which requires additional vram, more hdd access, etc). The reason why they like it is because it effectively loses no frame-rate, but still achieves improved visuals. The people who don't mind using additional vram usually use Vens or other stock part replacement models/textures.

Yeah, seems about right.  I'm personally using it simply because I hate how the stock textures look, but am occasionally forced to sue stock parts.

5 hours ago, Electrocutor said:

Honestly, it'd be nice if you created a list of generator texture names, such "white", "black", "gray", "bump", "metal", "red", "green", and "blue" that would auto-generate a single pixel texture.

No thanks -- if you really want to use that masked shader -- create some real mask textures for it.  It is not intended to be used like that, so I am not going to go out of my way to support a non-intended use.  Sure, you -can- use it like that, and I'm not going to stop you.  But I'm not going to go out of my way to make it easier either.

(alternatively, I'm far more open to 'feature requests' when they come with a PR.  You might be amazed at what I'm willing to accept when I don't have to do the all of the work on a feature that I won't use.  If you built a PR for this, and the textures were purely run-time generated (no assets included with the mod), I would more than likely be willing to accept it)

Edited November 28, 2017 by Shadowmage

[Shadowmage]

5 hours ago, Electrocutor said:

The shader keyword support sounds fun; if you can access them within ShaderLab, that'd give you more freedom to do interesting things without having to create additional shaders with tiny differences between them: for example, a cfg option of whether or not a diffuse texture is desaturated before applying the _Color1 blend (a GUI option), the ability to make procedural textures, etc.

Indeed; I'm hoping that it will allow for a bit more freedom both in writing the shader code, and in using the shader features.  As a bonus, it could result in some minor performance increase if I can disable features that are not in use (e.g. normal maps, emissives).

I have the preliminary code-side support written up, and have adjusted the two masked shader variants to use keywords to enable 'tinting mode', but have not yet had time to test any of it.  Will also need to write up custom Unity-editor UI wrappers for any shaders that use Keywords, as by default Unity does not support manipulating them in the editor (only through scripting).

Hopefully I'll get a chance later this week to work through this all, and be able to push out an update this weekend with all the new fun features.