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

[Shadowmage]

57 minutes ago, Electrocutor said:

Does the new syntax not allow shared texture sets like so (at the root of the file instead of under an @PART)?

AFAIK it is still supported and should still work.  I don't think I have any parts/etc using it, so I'm unable to test it.

(all of my SSTU parts use a entirely different setup for texture sets/texture-switching)

[Electrocutor]

1 minute ago, Shadowmage said:

AFAIK it is still supported and should still work.  I don't think I have any parts/etc using it, so I'm unable to test it.

(all of my SSTU parts use a entirely different setup for texture sets/texture-switching)

ManwithNoname got me, I had forgotten to switch from TEXTURESET{name} to textureSet.

[Shadowmage]

Just now, Electrocutor said:

Does the stock shader have any kind of transparency code in it (perhaps for that opacity parameter)?

I have a feeling that it is related to this change that I made in TU (that was intended to -fix- transparency issues under KSP 1.3.1):  https://github.com/shadowmage45/TexturesUnlimited/blob/794a4a884b055a068ea155321d4cdb6e146daeaa/Plugin/SSTUTools/KSPShaderTools/Util/TextureSet.cs#L345

No clue if it did what it was supposed to; it was right around the time that I was writing it that I started to get busy at work / irl, and it likely hasn't seen any real testing or validation.

[Urus28]

I have finally retrieve the shiny parts in KSP 1.4.1;  thank you @Shadowmage and @Electrocutor for your awesome work !

[Electrocutor]

@Shadowmage How tricky would it be to make a pop-up during KSP startup if the game is not being run as glcore? Something to the effect of "We've detected you are running the game in <d3d9/d3d11/etc>. Textures Unlimited will not work correctly without -force-glcore." Since previously, d3d11 worked for TU, quite a few people are using it again, even though it doesn't work right for 1.4.1.

You _could_ restore d3d11 functionality if you can figure out which faces are rendered wrong now in all d3d modes (and specifically what scenarios this happens in), then invert/rotate them as needed, but that'd be a good bit of code.

Edited March 25, 2018 by Electrocutor

[Shadowmage]

1 hour ago, Electrocutor said:

How tricky would it be to make a pop-up during KSP startup if the game is not being run as glcore?

Probably not too hard.  While I haven't dealt with KSP UIs much, it would be easy enough to look at AVC, etc see how they do the popup UIs during startup.  Will look into this for the next update, as its useful even for KSP's default DX9.

1 hour ago, Electrocutor said:

You _could_ restore d3d11 functionality if you can figure out which faces are rendered wrong now in all d3d modes (and specifically what scenarios this happens in), then invert/rotate them as needed, but that'd be a good bit of code.

I'm not entirely sure that I can.  I'm using the Unity built-in function to render cubemaps, so I don't actually have any control over orientation during rendering.  It also points towards the problem actually being in the Unity end of the code, but I haven't been able to confirm that yet.

[Electrocutor]

*sigh* serves me right for trying to be clever...

First, I tried to just set the shader to TU manually, then use variants to set properties...
... but the stock functionality allows only built-in shaders, built-in shader properties, built-in extra properties, and only sub-mesh selection of the first existing model.

 

I then attempted to inherit from ModulePartVariants and create my own implementation that supported something useful...
... but the method that actual updates materials and properties is static and thus cannot be overridden.
... and the GUI elements seem to be hard-coded to detect a PartModule named ModulePartVariants, so cannot be used for any inherited class.

 

This pretty much means there is only one possibility for hooking into the variant system to make it useful at all: entry points. That's a rabbit hole I'm absolutely not climbing into.

----

Basically, this means that if TU is going to be usable with any part that uses ModulePartVariants, you're going to have to code around it. Currently, ModulePartVariants seems to override material changes made by TU. At least in the case of B9 or Firespitter, TU worked fine so long as it was applied last, but this does not seem to work with Variants.

Edited March 26, 2018 by Electrocutor

[Ger_space]

@Electrocutor

Can't you make a listener to this game event https://kerbalspaceprogram.com/api/class_game_events.html#a7ef0f7a1a7c4a999b81d8c08c629e124

And apply the TU settings after its triggered?

[Electrocutor]

2 minutes ago, Ger_space said:

@Electrocutor

Can't you make a listener to this game event https://kerbalspaceprogram.com/api/class_game_events.html#a7ef0f7a1a7c4a999b81d8c08c629e124

And apply the TU settings after its triggered?

Perhaps; hadn't seen that one, thanks. Although... doing so would still require such code to be in TU itself, as ModulePartVariants cannot be altered to include functionality for TU.
 

Edited March 26, 2018 by Electrocutor

[Shadowmage]

2 hours ago, Electrocutor said:

Basically, this means that if TU is going to be usable with any part that uses ModulePartVariants, you're going to have to code around it.

I had/have no intentions of TU being usable for those parts.  Pick your poison (or rather, pick your texture-switch), and stick with it.  (same with B9/FS/ISFS; either use those, OR use TU; trying to use both is entirely unsupported)

I.E.  Parts that use the stock variant stuff will have to be reworked for use with TU -- all of the stock variant stuff will need to be removed, and replaced with TU equivalent.  Not sure what to do about the stock mesh-switching; I abhor their setup for those (multiple 'sub models' all within a single model file; pure ugly hack), and really don't want to write code to support it.

TLDR:  Stock variant switching should have never existed, certainly not the way they implemented it, and I have no intentions of supporting it.

[Manwith Noname]

At a snails pace...

Spoiler

 

[Electrocutor]

6 hours ago, Manwith Noname said:

At a snails pace...

 

The problems i have between ModulePartVariants and TU do not show themselves in the editor, only after launching and switching scenes. For other texture/model mods, you simply need KSPTextureSwitch as the last module in the list and everything works fine, but this doesn't seem to work for ModulePartVariants. Let me know if you find otherwise, and I'll see if I can spot any difference between out installs.

[Shadowmage]

7 minutes ago, Electrocutor said:

The problems i have between ModulePartVariants and TU do not show themselves in the editor, only after launching and switching scenes.

That is something that I might be able to solve; likely by simply running the TU material adjustment code a second time after the stock code has been run.  Probably the same solution is what would be needed to make the TU textures 'stick' on the stock fairings.

Not that I think that it is a good idea.  Pure cludge.  But it might be the only way to make it work with the stock code.

Hopefully I'll have more time to investigate these types of problems in the coming months.

Edit:  From a browsing of the API changes, it -looks- like I might be able to hook into the ' GameEvents.onEditorVariantApplied ' event to re-apply the TU-based material adjustments to the models on the part.  However, such a setup would be entirely incompatible with the 'inheritance' features -- all texture sets/material blocks would have to specify all of their parameters, as the only existing material would be the stock one (and not the previous TU selection).

Edited March 26, 2018 by Shadowmage

[Shadowmage]

On 3/25/2018 at 8:53 AM, Electrocutor said:

@Shadowmage How tricky would it be to make a pop-up during KSP startup if the game is not being run as glcore? Something to the effect of "We've detected you are running the game in <d3d9/d3d11/etc>. Textures Unlimited will not work correctly without -force-glcore." Since previously, d3d11 worked for TU, quite a few people are using it again, even though it doesn't work right for 1.4.1.

Something like....

(note that I forced the GUI to pop-up even though I'm using glCore;  in normal use it will only pop up if DX9/11/12, or legacy openGL are in use)

Should be available with the next update.  At least it is a nice little warning when the current gfx API is not fully supported.  Will probably add better instructions and/or links to a page that has better instructions.

[T-10a]

That's a good idea. I sometimes forget to add that runtime command and keep wondering why my shiny SSTU CSM isn't shiny before I remember my mistake

[Electrocutor]

@Shadowmage Please, let us know is 1.4.2 fixed the rendering of cubemaps for d3d9/11/12 in local+scaled.

[Shadowmage]

3 hours ago, Electrocutor said:

@Shadowmage Please, let us know is 1.4.2 fixed the rendering of cubemaps for d3d9/11/12 in local+scaled.

I'm not seeing anything in the change-log regarding rendering fixes.  Not even seeing a 'fixed cut-off icons when using OpenGL' in there anywhere...

I likely won't have time to recompile (or even download the update) until the weekend.  But if someone else wants to give it a go before then... please let me know how it turns out.

[Gordon Dry]

@Shadowmage it tried to hide in the backyard of my brain, but your last post gave me the self-confidence and permission to type it: "What about DirectX 11 and OpenGL and that?"

(Could contain irony)

[ItCameFromDuna]

I don't know if this is a matter of mis-installation, but I'm trying out the stock part conversion, and all the parts affected are extremely dark. They seem to be shaded properly, just too dark. Also, I have a TON of mods installed, it could be an incompatibility. I'm using game version 1.4.1.

 

Edited March 29, 2018 by ItCameFromDuna

[Shadowmage]

10 minutes ago, ItCameFromDuna said:

I don't know if this is a matter of mis-installation, but I'm trying out the stock part conversion, and all the parts affected are extremely dark.

It looks to me like your reflections have not been enabled.  What patch(es) are you using for the stock conversion?  (Electrocutor's patches included enabling the reflections last I looked at them, unsure of what other patch sets you could be using)

 

You can also try adding this patch to your gamedata folder somewhere:

@REFLECTION_CONFIG[default]
{
	%enabled = true
}

^^ Find your KSP/GameData/ folder.  Inside of it, make a new text file called 'reflections.cfg', paste the above text into it, save it, and re-launch KSP. 

(file can be named whatever you like, but I like to keep the filenames matching their purpose)

[ItCameFromDuna]

I should be using Electrocutor's patch, for both stock and Porkjet's Overhaul. I'll try your fix and see if it works. Thanks!

P.S. Just to clarify, the configs for the patches should just be in the GameData directory? Or is there somewhere within TU itself?

[ItCameFromDuna]

No avail. Do you want a log file or something?

[Shadowmage]

9 minutes ago, ItCameFromDuna said:

Just to clarify, the configs for the patches should just be in the GameData directory? Or is there somewhere within TU itself?

Anywhere within your GameData folder should be fine.  For these specific files you could even make your own sub-directory and place them there if you wanted.

 

-- there could also be a mod conflict at play.... are you using TextureReplacer and/or TextureReplacerReplaced, and/or WindowShine?  (not sure of the status of those mods in 1.4+, but they had potential for conflict with KSP 1.3.1)

 

1 minute ago, ItCameFromDuna said:

No avail. Do you want a log file or something?

Yes, please.  The KSP.log file from your main KSP folder would be great.   Would at least say if something specific had thrown an error, as well as letting me know if the reflections were actually enabled.  You can upload it to pastebin, dropbox, or even attach it directly to an issue ticket in the github tracker; whatever is easiest for you.

[ItCameFromDuna]

Back from dinner. Sorry for the delay. I'm not using any of the mods you listed (or any other graphics mod at all). How should I upload the log without freezing up my browser? It's 3.6 meg.

Edited March 30, 2018 by ItCameFromDuna

[Shadowmage]

1 hour ago, ItCameFromDuna said:

Back from dinner. Sorry for the delay. I'm not using any of the mods you listed (or any other graphics mod at all). How should I upload the log without freezing up my browser? It's 3.6 meg.

 

1 hour ago, Shadowmage said:

You can upload it to pastebin, dropbox, or even attach it directly to an issue ticket in the github tracker; whatever is easiest for you.