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

[T-10a]

Good news: I tried the -force-glcore option and it enables the new shaders. And man, they are pretty

Thanks to everyone! Maybe that info should be in the OP to let future users be aware of this.

[Shadowmage]

@Electrocutor

A quick heads-up that I (inadvertently) changed the _Metallic parameter name in the PBR/StockBumpedMetallic shader, which is now named _Metal.  Just letting you know as this impacts your stock-patch set.  A quick search to replace _Metallic with _Metal puts it all back in proper order (I had originally not intended to change that specific shader, as you were already using the property everywhere, but apparently I was a bit overzealous with my edits, and didn't catch it until yesterday).  Have to apologize for breaking it like that, it was not at all what I had intended originally.

As to the why -- Apparently Unity has some sort of internal conflict when the _Metallic property name is used, where it refuses to respect the default value as specified in the shader source file.  I'm guessing that Unity is using that variable name internally somewhere in one of their files, and it is getting pulled into the shader source from one of the #include's.  This was causing all _Metallic multiplier properties to default to zero, and breaking parts that were setup with actual metallic texture inputs (unless I adjusted their config to add the _Metallic property block and set the value back to 1 manually). 

As you shouldn't need to define/adjust parameters unless you are actually using them/changing them from default, I felt this was an important issue to get cleaned up for the Masked and standard PBR/Metallic shaders, as those will most often be used with proper texture inputs.  So, will probably be leaving the change in-place on the PBR/StockXXX shaders now that the damage has already been done; it was a fix for an actual issue after-all.

 

I also (possibly/maybe) added in a keyword-based 'tinting' mode to the Masked and PBR/Masked, but have not yet found time to do any testing or verification on that feature.  Hopefully will have time to get this tested (and cleaned up if necessary) in the next few days.  Would still require that mask textures be created for parts, but should allow for re-use of their existing DIFF/SPEC/MET textures, with the recoloring sliders acting as multipliers to the existing values.  Willing to investigate potential alternative 'tinting' code, as the current multiplier setup has some very obvious limitations, most notably in regards to the SPEC/MET recoloring (would be impossible to make a part more metallic or smoother than was defined by the original textures).

[Electrocutor]

I believe that _Metallic is what Unity actually uses in the editor (not as a multiplier), so if I had to guess, your default value was probably working, but all the materials already have it set to 0 from the Unity editor from Squad, and since you pull existing values it uses those instead of the default.

I'll make the change when I have time. Honestly, I had originally thought you'd want to include a generic cfg for use with stock parts and made it with that in mind, but you've made it very clear you do not wish for this mod to be used except in a mod-component scope, so I have instead begun working on my own mod.

As far as tinting via GUI goes, the ideal would be to have a red, green, and blue channel config such that you could assign different meshes into each channel. I've done this on my own by traversing the mesh uv and just procedurally created a texture to dump into the _MaskTex.

[Shadowmage]

20 minutes ago, Electrocutor said:

I believe that _Metallic is what Unity actually uses in the editor (not as a multiplier), so if I had to guess, your default value was probably working, but all the materials already have it set to 0 from the Unity editor from Squad, and since you pull existing values it uses those instead of the default.

Seems likely.  I couldn't find anything in the shader source code (even digging into the Unity shader source files), so it is very likely that the problem is a conflict with the Unity Editor and/or KSP assigning those property values at some point.

 

22 minutes ago, Electrocutor said:

I'll make the change when I have time. Honestly, I had originally thought you'd want to include a generic cfg for use with stock parts and made it with that in mind, but you've made it very clear you do not wish for this mod to be used except in a mod-component scope, so I have instead begun working on my own mod.

Please don't take it personally, as it absolutely is not (you've done excellent work on the stock patches).  Rather it is me trying to pro-actively reduce support posts from people who don't examine the contents of the mods they install, and then come to the forums with posts of 'why are the stock parts looking different'.  I learned long ago to not touch stock or other mods parts as part of any 'default' mod setup; I simply lack the patience to deal with support requests from people who don't bother looking at what they are installing.  (Do I personally want to include the patches?  Yes, absolutely.  Am I willing to deal with support for people 'surprised' by the changes?  No, makes me depressed every time I see one of those posts)

I would not be opposed to distributing the stock-conversion patch through the Textures Unlimited OP and/or repository, but it would have to be done as a separate secondary download that users could optionally install.  This would keep the base distribution 'clean' and easy for other mods' to distribute, while still giving a local source for the patches (and/or any assets you may want or need to include).  If this is something you are interested in, please let me know -- I can give you developer access to the repository so that you can update the patches/files as needed (or alternatively, can link into an external repository that you manage/maintain/setup).

Alternatively, if/when you get your mod going and established/published/released, I can certainly add links and some references and recommendations for it.  Is the very least I can do considering the effort you've put into creating the patches.

 

28 minutes ago, Electrocutor said:

As far as tinting via GUI goes, the ideal would be to have a red, green, and blue channel config such that you could assign different meshes into each channel. I've done this on my own by traversing the mesh uv and just procedurally created a texture to dump into the _MaskTex.

Hmmm.... interesting proposition.  Something like that should be doable (entirely mesh based, completely removing the mask texture).  Would require a new shader, and of course some adjustments to config files, but I don't see any technical barriers (just time to implement shaders + write configs).  Will give it bit more thought to figure out exactly what would be needed, and if I don't come up with any show-stopping problems, will add it to the official TODO list.   Would preclude the ability to

Curious -- you say you are doing it procedurally -- are you currently using plugin code to create/output these mesh-based mask textures?

[Electrocutor]

14 minutes ago, Shadowmage said:

I would not be opposed to distributing the stock-conversion patch through the Textures Unlimited OP and/or repository, but it would have to be done as a separate secondary download that users could optionally install.  This would keep the base distribution 'clean' and easy for other mods' to distribute, while still giving a local source for the patches (and/or any assets you may want or need to include).  If this is something you are interested in, please let me know -- I can give you developer access to the repository so that you can update the patches/files as needed (or alternatively, can link into an external repository that you manage/maintain/setup).

I'll think about it. I made it because it was easy, took little time, and seemed useful to make stock parts shiny. I never really intended to support it or anything since it's just a cfg.

 

26 minutes ago, Shadowmage said:

Alternatively, if/when you get your mod going and established/published/released, I can certainly add links and some references and recommendations for it.  Is the very least I can do considering the effort you've put into creating the patches.

It will probably be a very long time before my mod is released. I've been working on parts of it for a few years now; am hoping to make it usable and polished enough to release sometime after 1.4. The vast majority is non-graphical so I will probably just make/keep a couple cfgs for making shiny parts for the time being. Also, the patches weren't hard at all, just takes some preview time to check that there aren't any strange-looking parts (like the super-shiny parachutes that were caught earlier).

 

49 minutes ago, Shadowmage said:

Curious -- you say you are doing it procedurally -- are you currently using plugin code to create/output these mesh-based mask textures?

You mean your plugin? No, I just wrote my own code, and the Texture2Ds are just created in RAM and not written out.

[Electrocutor]

Like so?

		PROPERTY
		{
			name = TINTING_MODE
			keyword = true
		}

 

[Shadowmage]

2 hours ago, Electrocutor said:

Like so?

		PROPERTY
		{
			name = TINTING_MODE
			keyword = true
		}

 

 

Rather:

PROPERTY
{
	keyword = TINTING_MODE
}

Support for keywords is rather primitive, with only 'enable keyword' being supported at the moment.  But the above should switch the masked shader to tinting mode (if I did the shader-side code properly).

[Electrocutor]

Seems to work as intended.

I am using it by setting _MaskTex to the diffuse texture. Doing so allows me to change any redness, greenness, or blueness to different colors while maintaining the original as default.

It occurs to me that it'd be nice to be able to assign Main, Secondary, and Detail to one or more white, gray, black, primary, secondary, or tertiary colors so as to replace the colors specified in the original diffuse to whatever is set in the GUI. A shader like that would need some thinking though as you would want to maintain the color intensity even while shifting hues. Being able to do this would likely also get more people to adopt this mod as it would then require no extra changing or adding of textures to accomplish the desired result while still being extremely accurate.

----

Unrelated:

• I updated the stock cfg to _Metal for v1.0.0.5
• I added a cfg for @Porkjet's part overhaul (https://drive.google.com/open?id=1Soer13EMGcRYZbq9Rty4A1LTCN1IMXHG)
  • It utilizes some different different features than the stock one on a trial basis to see if people like the options or would rather just have a fixed 'make it metal' without having right-click spam in the editor.

----

Edited December 11, 2017 by Electrocutor

[Electrocutor]

For tinting, what should be the default color to maintain the original texture colors? It seems that 127,127,127 makes everything darker and 255,255,255 causes everything to become washed out.

[Agustin]

5 minutes ago, Electrocutor said:

For tinting, what should be the default color to maintain the original texture colors? It seems that 127,127,127 makes everything darker and 255,255,255 causes everything to become washed out.

I really don't care about the original colors. If it looks good, then make that default. That is at least my opinion...

Edited December 11, 2017 by Agustin

[Shadowmage]

14 minutes ago, Electrocutor said:

For tinting, what should be the default color to maintain the original texture colors? It seems that 127,127,127 makes everything darker and 255,255,255 causes everything to become washed out.

For 'tinting mode' -- the diffuse texture should be assigned to the diffuse slot.  The mask texture should consist of R, G, or, B values equaling 1 for tinted areas (or a normalized RGB component; cannot exceed combined value of '1').

With that setup, a 'Recoloring GUI' selection of 255,255,255 for the chosen 'Main/Second/Detail' color for that section should result in the exact same output as the input diffuse texture.  It is a very basic 'color multiply' form of tinting (if setup properly, you should never be able to make the output brighter than the input).

Keep in mind that the R,G,B values in the mask texture are intended to be applied to singular parts of the mesh.  It should be either R, or G, or B, but should rarely, if ever, be a combination of the three (and when it is, it must be normalized to an output combined output of '1').

So, Inputs should be:
Diffuse texture = actual diffuse texture.
Mask texture = consisting of pure R, G, or B values.  Sections in the mask with 'R' will be tinted by the 'Main Color', masked sections of 'G' will be tinted by the 'Second Color', and masked sections of 'B', will be tinted by the 'Detail Color' input.
Spec/Met = actual specular/metallic textures.  The specular/metallic sliders function as multipliers to the input textures -- so it is impossible to make something have higher smoothness or metallic value than the input base texture contains.
Main/Second/Detail color selections of 255, 255, 255
Spec/Metallic color selections of 255, 255

 

Edit:  Yes, the tinting mode is of questionable use and rife with limitations.  Which is why I have never used the system myself, nor could I see myself ever using it for anything.  The limitations and problems regarding recoloring of existing full-color textures are just too large for me to accept (or solve).

Edited December 11, 2017 by Shadowmage

[Agustin]

4 minutes ago, Shadowmage said:

For 'tinting mode' -- the diffuse texture should be assigned to the diffuse slot.  The mask texture should consist of R, G, or, B values equaling 1 for tinted areas (or a normalized RGB component; cannot exceed combined value of '1').

With that setup, a 'Recoloring GUI' selection of 255,255,255 for the chosen 'Main/Second/Detail' color for that section should result in the exact same output as the input diffuse texture.  It is a very basic 'color multiply' form of tinting (if setup properly, you should never be able to make the output brighter than the input).

Keep in mind that the R,G,B values in the mask texture are intended to be applied to singular parts of the mesh.  It should be either R, or G, or B, but should rarely, if ever, be a combination of the three (and when it is, it must be normalized to an output combined output of '1').

So, Inputs should be:
Diffuse texture = actual diffuse texture.
Mask texture = consisting of pure R, G, or B values.  Sections in the mask with 'R' will be tinted by the 'Main Color', masked sections of 'G' will be tinted by the 'Second Color', and masked sections of 'B', will be tinted by the 'Detail Color' input.
Spec/Met = actual specular/metallic textures.  The specular/metallic sliders function as multipliers to the input textures -- so it is impossible to make something have higher smoothness or metallic value than the input base texture contains.
Main/Second/Detail color selections of 255, 255, 255
Spec/Metallic color selections of 255, 255

 

Edit:  Yes, the tinting mode is of questionable use and rife with limitations.  Which is why I have never used the system myself, nor could I see myself ever using it for anything.  The limitations and problems regarding recoloring of existing full-color textures are just too large for me to accept (or solve).

yeah, my thoughts exactly

[Electrocutor]

Okay... As you know, I am making these quick patches by just using cfgs and not creating any textures for them. Using the diffuse as input for the mask works in mediocrity, but it will at least give people the ability to adjust most colors around a bit even if they will not equate to the actual color they are selecting (it will instead be hue shifting).

The most obvious parts will be those originally painted near-white, which coincides with how most people have created their textures for mods.

 

[Shadowmage]

2 minutes ago, Electrocutor said:

Okay... As you know, I am making these quick patches by just using cfgs and not creating any textures for them. Using the diffuse as input for the mask works in mediocrity, but it will at least give people the ability to adjust most colors around a bit even if they will not equate to the actual color they are selecting (it will instead be hue shifting).

The most obvious parts will be those originally painted near-white, which coincides with how most people have created their textures for mods.

 

Yeah, I really need to figure out a better way to do the 'tinting' mode for the recoloring shader/system.  The current setup is admittedly very simplistic and barely functional/usable.  (Really though, the recoloring system was never intended to be used for tinting like this; from its inception it was always designed to be used with custom-built base-gray textures; apparently there is need for a separate and secondary tinting system, which is going to take time to develop properly)

Hmm.. just thinking out loud a bit here....

There really should be some way to extract Hue, Saturation, Value (HSV) out of an RGB color (fairly certain there is, but I've always dealt with color values as RGB).  From there, it should be possible to keep the S+V, while replacing the just the H.  That should allow for keeping the existing details, while adjusting only the color.

Seems that the 'tinting system' would require a new GUI for the purpose, as its inputs will be different than the current inputs (being more HSV based rather than color based).  Might be able to find a way to keep the current GUI, but will definitely require some thought (as stated, I'm not used to dealing with colors as anything but RGB values).

 

[Electrocutor]

It could still be accomplished with RGB values. The idea is that you have 3 color selections, and you want to assign them to something that is already colored. So for example: change everything that is gray to metal, everything that is orange to blue, and everything that is white to gold. The question is how to equate primary, secondary, and tertiary colors into RGB ranges, as it is mostly about ratios between the R, G, and B value to know the difference.

If you can come up with a really intelligent way of accomplishing it, I suspect that many others that use Unity would be interested in such a shader for modding because it would create an ability to customize without any texture work on the modder's time. That said, the current implementation works fine, it's just a bit clunky and requires some thought about Main replacing Red, Secondary replacing Green, and Detail replacing Blue.

[Cheesecake]

I have some reflection-changing every second.
Here are some pics.

https://imgur.com/a/ARwTe

Is this caused by Kopernicus?

[Shadowmage]

2 minutes ago, Cheesecake said:

I have some reflection-changing every second.
Here are some pics.

https://imgur.com/a/ARwTe

Is this caused by Kopernicus?

More than likely caused by 'Texture Replacer Replaced' if you have it installed.  Apparently it causes some conflicts if installed.

Kopernicus/MFI should only cause problems on terrain textures/rendering when DX11 is used (unrelated / not caused by TexturesUnlimited).

[Agustin]

Electrocutor, where is the last stock Cfg conversion file?

Edited December 12, 2017 by Agustin

[Jimbodiah]

Spoiler

 

Edited December 12, 2017 by Jimbodiah

[Electrocutor]

1 hour ago, Agustin said:

Electrocutor, where is the last stock Cfg conversion file?

I'm currently redoing it to make better use of more available features. I'm using Porkjet's part overhauls as a grinding stone. You can still pull the file with the same link from a few pages back.

I just uploaded a new Porket's Part Overhauls cfg...

Edited December 12, 2017 by Electrocutor

[Electrocutor]

@Shadowmage Do you have any inclination to expand on the TextureSwitcher to allow model switching as well? For example, simply have an arrow to switch between the T400 fuel tank that is stock, Ven, and Porkjet while just having a single part? I think just having a model location and scale would be sufficient as far as options go and it'd be up to the modder to make sure the models used had their hard points line up properly. I'm not sure if Unity or KSP would get angry at doing that though.

[Shadowmage]

5 minutes ago, Electrocutor said:

@Shadowmage Do you have any inclination to expand on the TextureSwitcher to allow model switching as well? For example, simply have an arrow to switch between the T400 fuel tank that is stock, Ven, and Porkjet while just having a single part? I think just having a model location and scale would be sufficient as far as options go and it'd be up to the modder to make sure the models used had their hard points line up properly. I'm not sure if Unity or KSP would get angry at doing that though.

I don't currently have any plans along those lines. 

Mostly because I already have exactly that all built and working in SSTU (its actually the cornerstone of the mod).  A full model-switching setup, with individual texture-set (and recoloring) handling for each model, complete with attach node positioning (optional; single node, multi-node, etc), mass and cost adjustments (also optional), positioning of the selected model relative to the parts COM (again, optional), scaling of the model (optional), updating of drag cubes on model changes (optional-configurable), and much more.  The feature-set is actually ridiculously long, and growing; and that is all just for the stand alone 'model-switch' module (there are what equate to multi-model-switch modules as well).

I might be willing to port some of that over to TU at some point in the future, but it would likely have to come sometime after I finish overhauling the system(s) (tentatively scheduled for sometime around KSP 1.4, whenever that is).  It is currently a bit of a mess back-end wise as it has 'evolved' over the past couple of years, so is currently undergoing a much needed refresh; as it will be a considerable change to the part-modules and configs, and more than likely craft/vessel breaking, I've scheduled it to coincide with the next major KSP version (hopefully, if I can get it done in time... and if I'm not then waiting for months for KSP to update).

[Cheesecake]

19 hours ago, Shadowmage said:

More than likely caused by 'Texture Replacer Replaced' if you have it installed.  Apparently it causes some conflicts if installed.

Kopernicus/MFI should only cause problems on terrain textures/rendering when DX11 is used (unrelated / not caused by TexturesUnlimited).

I have the older Texture Replacer.

[Shadowmage]

1 minute ago, Cheesecake said:

I have the older Texture Replacer.

Probably the same conflict.

Does the problem go away when you remove Texture Replacer?  If yes, then that is the problem.  If no -- please file a bug report on the TU repository; be sure to include the KSP.log file.

[Jimbodiah]

I had the same thing when running mods with Texture Replacer (not so much TR Replaced that I recall) where the reflections in TU would flicker. After removing TR the problem went away.

Most mods that use TR can work just fine without it, just remove the TR folder.