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

[Shadowmage]

Testing release is available, with a potential solution to the inverted cube-faces in DX9/DX11:

https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.1.2.14a

See the link for downloads and instructions on how to activate the 'alternate rendering' fix.  (you must activate the fix manually for now)

 

If this solution seems to work, I'll clean it up to be used automatically with DirectX, and remove the warning when using DX11.  The DX9 warning will stay, as there are still other issues with cubemap blurring in DX9.

[Manwith Noname]

As a sort of amendment to my last post, I was mistaken slightly. Flare doesn't seem to be one of the all caps meshes. Here's a list I apply generically to texture sets...

		excludeMesh = FlagTransform
		excludeMesh = flagTransform
		excludeMesh = FLAG
		excludeMesh = Flag
		excludeMesh = flare
		excludeMesh = Flare

...three cheers for standardisation. That will catch most of the stock meshes you probably don't want to touch with your main material.

[Shadowmage]

Anyone had a chance to give the above DX11-fixing dev-test-release a try?  Ran into any problems with it?

[Leandro Basi]

9 minutes ago, Shadowmage said:

Anyone had a chance to give the above DX11-fixing dev-test-release a try?  Ran into any problems with it?

I Will try tonight.

[UnanimousCoward]

1 hour ago, Shadowmage said:

Anyone had a chance to give the above DX11-fixing dev-test-release a try?  Ran into any problems with it?

On a test install of KSP 1.4.2 -force-d3d11 with only Textures Unlimited and Module Manager 3.0.7, "directXFix" config enabled, the icons in the VAB are a rather fetching shade of blue:
 

Spoiler

 

Pretty, but impractical. Same thing with MM 3.0.6.

In game, from just a very quick test with a few random shiny parts, the actual reflections looked fine to me. A few parts (e.g. the basic fin) didn't look quite as shiny as I remember (using Electrocutor's stock config), but that's likely to be a combination of shoddy memory, subjectivity, and anomaly-hunting. Nothing else glitchy or weird that I could see.

Edited May 7, 2018 by UnanimousCoward
due to idiocy

[Shadowmage]

5 minutes ago, UnanimousCoward said:

 the icons in the VAB are a rather fetching shade of blue:

Yeah, that is a stock bug with their shaders... something they really need to fix internally.  (I may have a workaround... but why? stock just needs to fix their code...)

6 minutes ago, UnanimousCoward said:

In game, from just a very quick test with a few random shiny parts, the actual reflections looked fine to me.

Good to hear, and that is the kind of information that I'm looking for (e.g. information on how the actual parts look).

Anyone tested with Scatterer/EVE/KS3P to see if the 'fix' causes any issues in any of those mods?

[Leandro Basi]

1 minute ago, Shadowmage said:

Yeah, that is a stock bug with their shaders... something they really need to fix internally.  (I may have a workaround... but why? stock just needs to fix their code...)

Good to hear, and that is the kind of information that I'm looking for (e.g. information on how the actual parts look).

Anyone tested with Scatterer/EVE/KS3P to see if the 'fix' causes any issues in any of those mods?

I have test now, and without activating alternate fix with D3D11 scatterer, EVE and KS3P is ok!

[Leandro Basi]

19 hours ago, Leandro Basi said:

I have test now, and without activating alternate fix with D3D11 scatterer, EVE and KS3P is ok!

I have to rewrite my test.I forgot to remove the directory with KSP-1.4-fixes.dll, after removing, the problem with the icons came back. Where should I write the patch? Should any specific name be given to the .cfg file?

[Shadowmage]

1 minute ago, Leandro Basi said:

I have to rewrite my test.I forgot to remove the directory with KSP-1.4-fixes.dll, after removing, the problem with the icons came back. Where should I write the patch? Should any specific name be given to the .cfg file?

The icon problem has nothing to do with TU, it is purely a stock problem with DX11.  Neither am I interested in how the icons look, or in fixing them.  (that patch/mod you deleted was Electorcutor's 'fix' for the icons; so if you want your icons fixed, restore whatever it is you removed)

I'm specifically interested if the reflections are proper and working while in flight.  If you launch a craft with metallic parts, are the environment reflections proper?  Any problems with EVE/Scatterer/etc?

[Leandro Basi]

14 minutes ago, Shadowmage said:

The icon problem has nothing to do with TU, it is purely a stock problem with DX11.  Neither am I interested in how the icons look, or in fixing them.  (that patch/mod you deleted was Electorcutor's 'fix' for the icons; so if you want your icons fixed, restore whatever it is you removed)

I'm specifically interested if the reflections are proper and working while in flight.  If you launch a craft with metallic parts, are the environment reflections proper?  Any problems with EVE/Scatterer/etc?

Reflections is working

[Rallyman03]

On 5/6/2018 at 2:10 PM, Shadowmage said:

Testing release is available, with a potential solution to the inverted cube-faces in DX9/DX11:

https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.1.2.14a

See the link for downloads and instructions on how to activate the 'alternate rendering' fix.  (you must activate the fix manually for now)

 

If this solution seems to work, I'll clean it up to be used automatically with DirectX, and remove the warning when using DX11.  The DX9 warning will stay, as there are still other issues with cubemap blurring in DX9.

Any idea if this fix also works for DX12? I guess I could test it and report back. 

[Manwith Noname]

Did the test release remove some logging? Is it some strange quirk of having shifted to DX11 from OpenGL? Or did I do something that stopped it? Maybe I imagined it? I had previously noticed in the logs TU making entries about missing textures for normals and emissives, then creating a placeholder. I guess I could revert back to OpenGL to narrow it down a bit. I was thinking of using that info to assign my own placeholders rather than digging through the game folders.

Anyway, main reason for posting was to report on DX11 reflections...

Spoiler

I first noticed something when checking out window reflections but it was always at obscure angles and just creeping in at the edge so I could never really get a shot that would be helpful...then this happened. Hope it's helpful in some way.

 

Edit: Hold that thought...it might just be me being an idiot...I forgot to enable the fix in the configs.

Edited May 11, 2018 by Manwith Noname

[Shadowmage]

36 minutes ago, Manwith Noname said:

Did the test release remove some logging? Is it some strange quirk of having shifted to DX11 from OpenGL? Or did I do something that stopped it?

Logging is enabled through some configs -- https://github.com/shadowmage45/TexturesUnlimited/blob/master/GameData/000_TexturesUnlimited/GeneralConfiguration.cfg#L6-L9

It may be that the debug statements you were always logged, but may now only be logged when the debug and log replacements are enabled.  Try patching/enabling those values, and see if the log statements are still 'missing'.

FYI -- I'm still seeing them in my logs:

[LOG 12:50:48.653] ERROR: KSPShaderLoader - Texture could not be located for name: SSTU/Assets/SC-TANK-LV-PH-AO for texture slot: _AOMap while loading textures for material: Default-Material (Instance) (UnityEngine.Material)
[LOG 12:50:48.654] Replacing empty textureslot: _Emissive with color: 0,0,0,0
[LOG 12:50:48.654] Replacing empty textureslot: _Emissive with color: 0,0,0,0

 

36 minutes ago, Manwith Noname said:

I first noticed something when checking out window reflections but it was always at obscure angles and just creeping in at the edge so I could never really get a shot that would be helpful...then this happened. Hope it's helpful in some way.

 

Edit: Hold that thought...it might just be me being an idiot...I forgot to enable the fix in the configs.

Hehe, yeah, the DX 'fix' is for that specific issue.  Certainly it is not going to 'fix' anything unless it is enabled

 

Edit:

Logging -- yep, I put that debug statement behind a logging-enabled check.... so enable the logging and debug features in that config file if you want to see that info.

https://github.com/shadowmage45/TexturesUnlimited/commit/3eba6bdd505eda9e1bbece15e1f9988bd589bcf7

Edited May 11, 2018 by Shadowmage

[Manwith Noname]

@Shadowmage

Yeah, I think I turned it on and forgot about it so when I replaced the files, it reset. I'm still seeing bug eyes on the putnik with the fix though. Hmmm, will it spit a comment in the logs so I can verify it has enabled?

Edit: Ok, found this...

[LOG 21:29:03.749] Config(@REFLECTION_CONFIG[default]) TU_Stock_Recolour/141_Stock_Recolour/@REFLECTION_CONFIG[default]

So, it appears it picked it up.

Another edit: Just so you know it's not the enable reflections patch, I have that in a separate file, which is where I first applied the fix but I moved it to the main patching for testing...

[LOG 21:29:03.774] Config(@REFLECTION_CONFIG[default]:NEEDS[TexturesUnlimited]) TU_Stock_Recolour/Enable_Reflections/@REFLECTION_CONFIG[default]:NEEDS[TexturesUnlimited]

 

Edited May 11, 2018 by Manwith Noname

[Shadowmage]

52 minutes ago, Manwith Noname said:

@Shadowmage

Yeah, I think I turned it on and forgot about it so when I replaced the files, it reset. I'm still seeing bug eyes on the putnik with the fix though. Hmmm, will it spit a comment in the logs so I can verify it has enabled?

Edit: Ok, found this...

[LOG 21:29:03.749] Config(@REFLECTION_CONFIG[default]) TU_Stock_Recolour/141_Stock_Recolour/@REFLECTION_CONFIG[default]

So, it appears it picked it up.

Another edit: Just so you know it's not the enable reflections patch, I have that in a separate file, which is where I first applied the fix but I moved it to the main patching for testing...

[LOG 21:29:03.774] Config(@REFLECTION_CONFIG[default]:NEEDS[TexturesUnlimited]) TU_Stock_Recolour/Enable_Reflections/@REFLECTION_CONFIG[default]:NEEDS[TexturesUnlimited]

 

Try enabling the fix from the TU-debug GUI.  Should be labeled 'alternate render' or something similar.  (I didn't test the config based method... so it could be not fully working...)

When changing scenes it should dump the entire 'reflection config' node to the log file -- so you should be able to check that to see if the fix was enabled in the config (but as-per above, the config based toggle might not be fully working)

[Manwith Noname]

@Shadowmage

Good news!

Spoiler

That did the trick.

 

Edit: Oh, what might be happening is losing the setting between scenes. I enabled it in the hangar but had to redo it on the runway.

Edited May 11, 2018 by Manwith Noname

[Shadowmage]

3 minutes ago, Manwith Noname said:

That did the trick.

Thanks for the confirm.  I'll double check that the config-based toggle is actually working before pushing out any official release with this fix.

[caipi]

On 5/11/2018 at 11:16 PM, Shadowmage said:

Try enabling the fix from the TU-debug GUI.

Sorry for the very stupid question, but how do I open the TU debug GUI? I must have missed the shortcut. I've already checked the first post and several pages in this thread, the github wiki, the generalconfig file. But somehow I cannot find it. Sorry! :-/

[Manwith Noname]

@caipi

The best thing to do is create a config in your GameData directory that includes this...

@REFLECTION_CONFIG[default]:NEEDS[TexturesUnlimited]
{
	%debug = true
}

...then when you install updates of the TU package you will not forget you enabled things months ago and wonder why they no longer function.

 

Edit: Oh...this will enable a little TU button in the toolbar you'll need to click.

Edited May 13, 2018 by Manwith Noname

[caipi]

I've been playing for an hour or so now with DX11 and I didn't run into any problems anymore after I enabled the debugging (thanks to @Manwith Noname !)

However I did notice something weird before I activated the debug: Some metallic textures were flickering. It seems to me as if they were flickering between the alternate render mode (true/false), both with ks3p enabled or disabled, that did not matter. Enabling the debug stabilized/stopped it. It also happened in space.

But see for yourself (the pod): https://imgur.com/a/MPi00TH

Also I can confirm that the setting is lost between the scenes. Might this be related to the first flickering bug?

[Shadowmage]

2 minutes ago, caipi said:

I've been playing for an hour or so now with DX11 and I didn't run into any problems anymore after I enabled the debugging (thanks to @Manwith Noname !)

However I did notice something weird before I activated the debug: Some metallic textures were flickering. It seems to me as if they were flickering between the alternate render mode (true/false), both with ks3p enabled or disabled, that did not matter. Enabling the debug stabilized/stopped it. It also happened in space.

But see for yourself (the pod): https://imgur.com/a/MPi00TH

Also I can confirm that the setting is lost between the scenes. Might this be related to the first flickering bug?

If you really want to see what is 'going on' with the reflections -- enable the 'debug sphere' from the TU debug menu.

Those screenshots unfortunately don't really tell me much... try doing it again with the debug-sphere enabled.

(btw, just enabling the debug menu/debug mode shouldn't do... anything; if it does change reflections, you should file that as a bug on the tracker, including the screenshots of the 'debug sphere')

 

[caipi]

Apologies for the late reply. I haven't really had much time for KSP the past few days.

Adding the debug mode didn't actually stop it, you were right, of course. I was actually surprised myself.

Turns out, the flickering was an issue caused by TextureReplacerReplaced (0.5.4), which has not yet been updated for KSP 1.4.x yet, in connection with TU. The flickering only appeared in EVA and it stopped once "alternate render" was set to "true" (which, unfortunately, was not yet saved across scenes in your dev version).

Switching to TextureReplacer 3.1 (I just need my custom skybox and colonization suits! :] ) resolved the issue as well.

[Burning Kan]

2 hours ago, caipi said:

I just need my custom skybox and colonization suits

for this u can also try D.I.R.T ,just in case

 

[Jimbodiah]

When FASA starts using your textures... 

• optionally ships a first TexturesUnlimited config for the same parts, but is disabled by default

 

I think this was one of the first mods to have a reflective texture (apollo). Good to see more traction for this API.

[Manwith Noname]

I would like to open a bit of a discussion with regard to standardising texture switching. Why? When there was only one or two people openly working on stock TU projects it was a little messy but manageable. As more and more people come out of the woodwork with their own projects, keeping things in line with one another becomes a bit of a headache. Even when trying to make sure my configs worked with the only ones I was aware of, I ended up having to write patches to other peoples work so they would function correctly. I was also trying to write my configs so they would function on their own but also work with other patches if they are present.

Having gone through this process and thought about ways in which to solve the problem, I've come to the conclusion that the simplest way for everyone to ensure their patches work with others is to devise a standardised setup which config creators follow. The standardised pack would be untouched by the authors of individual patches but distributed with them. So as people create their own configs, end users simply download a pack they're interested in, throw it in their install and regardless of what other configs exist, everything plays nice and each author doesn't have to think about what other people are doing.

The main drawback of doing this is it will break any stock config patches already existing. For a lot of parts, there isn't really an issue but where available, it's nice to split meshes in to groups for extra possibilities, particularly with recolouring. In the long run however, I feel this will benefit all config creators.

With that said, here's a first draft of the proposal.

It's not for placing in your game. It's simply for people to review and offer up mesh splits they might like to see or raise questions and concerns with problems I may not have considered.

 

Edit: Don't look at the fairing code....

Edited May 16, 2018 by Manwith Noname