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

[Remanent]

Does this work with stock parts at all? or just your sstu pack? I see some of these pictures with the highly reflect and metallic looking rockets, but if it's part of a texture pack, i'm not seeing where to get that pack at.  The end results are amazing, but as i've been out of KSP for a while, returning to all this kinda blows my mind.

[Shadowmage]

52 minutes ago, Remanent said:

Does this work with stock parts at all? or just your sstu pack? I see some of these pictures with the highly reflect and metallic looking rockets, but if it's part of a texture pack, i'm not seeing where to get that pack at.  The end results are amazing, but as i've been out of KSP for a while, returning to all this kinda blows my mind.

By default, TexturesUnlimited doesn't include any textures or configs.  Any support for the PBR shaders/textures will need to come from specific mods.

As SSTU is one of my personally maintained mods, I have included an SSTU-PBR expansion pack that can optionally be installed to activate PBR shaders/textures on most SSTU parts (WIP... not everything is done/finished/supported yet).  It can be found here ->  https://github.com/shadowmage45/SSTULabs/releases/tag/PBR-0.1.0.4

For stock parts -- @Electrocutor has done an excellent job working on a set of patches that converts the stock parts to use the PBR shaders while re-using their existing textures.  Its last version was a single config file, and didn't require any additional assets.  It can be found somewhere in this thread, likely a few pages back.  I do not think there is any official release thread for that work (yet?).

For other mods -- you would have to ask the mod author to specifically support/use TexturesUnlimited / PBR shaders/textures.  So far the interest has been very minimal from the major modders and established mods, though a few newer modding projects have elected to use it for their parts ( @bcink is using it on both the JWST and KEAM mods, I think there is also a New Glenn mod using it for at least some of the parts).

[Remanent]

@ShadowmageThank you for taking your time to reply.

The post you referred to is here.  Thanks @Electrocutor for your work.

[vossiewulf]

15 hours ago, Shadowmage said:

So far the interest has been very minimal from the major modders and established mods

Moving forward, we can refer to them as the "horse and buggy" crowd

I kid! It's considerable work for the folks with mods of many parts to rework all the textures.

[Shadowmage]

5 hours ago, vossiewulf said:

I kid! It's considerable work for the folks with mods of many parts to rework all the textures.

Indeed; I can't hold it against anyone, and I know first-hand how much work it can be.  If you already have an established texture style and processes, why disrupt that for days/weeks to learn the new stuff, and then spend more days/weeks converting existing work?  Most sane people would term it a 'poor use of time' at best.  To further complicate things the stock-alike texturing really doesn't lend itself to easy PBR conversion; so all of these large mods using stock-alike texturing setups would either get little benefit out of the shaders, end up with strange looking parts if converted as-is, or would have to spend an even larger amount of time authoring new PBR textures for everything.

On the other hand, I also can't understand why someone would not want to use PBR textures/shading if given the choice.  The visuals, especially on metals (but really on everything), is just so much better due to the environmental lighting.  Metals get the double-bonus of being able to finally be shiny.

[Pol]

I imagine how lack of attention after much work can be disappointing. Some would think it not worth it, some can worry about consistency with other parts, some maybe do not want dependency. But it will be nice if people made at least optional configs. Even without additional maps just pbrstock is great imrovements in shading and lighting compared to stock. And this is not  about just polished metall balls.

launchclamps make my probe to stuck at launchpad, happens on stage separation. It's upadates correctly until staging and then it show launchpad grid until scenechange/ at least according to my observations.

[Shadowmage]

2 minutes ago, Pol said:

launchclamps make my probe to stuck at launchpad, happens on stage separation. It's upadates correctly until staging and then it show launchpad grid until scenechange/ at least according to my observations.

Yeah, I'm working on sorting out some multi-vessel reflection probe blending problems for the next release.

Should hopefully have it all cleaned up for an updated release tonight or tomorrow.

 

3 minutes ago, Pol said:

But it will be nice if people made at least optional configs.

Indeed -- they don't need to switch over to PBR completely.  It is perfectly usable as an 'optional-PBR-conversion' type expansion pack/etc.  This is exactly how I have it setup for SSTU -- by default it uses the legacy KSP shaders, but you can install the optional PBR-expansion pack, and get access to all of the nice shiny visuals.

[bcink]

2 hours ago, Shadowmage said:

On the other hand, I also can't understand why someone would not want to use PBR textures/shading if given the choice.  The visuals, especially on metals (but really on everything), is just so much better due to the environmental lighting.  Metals get the double-bonus of being able to finally be shiny.

 

I did not know this was the case or perhaps I would have gone that route? Maybe I can investigate this on my next project...

[Shadowmage]

2 minutes ago, bcink said:

I did not know this was the case or perhaps I would have gone that route? Maybe I can investigate this on my next project...

For non-metallic textures, the differences are subtle.  For example your KEAM wouldn't look too much different with PBR shaders.  The largest notable difference is that it could pick up some of the coloring of whatever planet/body it is orbiting; a slight blue tint on the underside when orbiting Kerbin/Earth; orange tint around Duna, purple around Eve, etc.  Metals do the same thing, but it is far more visible.  Glossy non-metals as well are highly impacted, and actually start to look glossy (rather than just 'shiny').

I personally find that subtle lighting to be very effective though.  It makes the model seem like it actually belongs in whatever environment it is, rather than looking 'copy-pasted' into the image.  Its like the difference between a good photo-shopping job (good lighting on the edited bits), versus a bad photo-shopping job (where the edited bits stand out, as they simply 'look' out of place for the scenes lighting).

[Shadowmage]

Posting up a quick pre-release of the version that I anticipate publishing tomorrow.

https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.0.0.5-pre

Should be fully backwards-compatible with existing releases, and should be able to be updated in-place.  Quite a few changes and optimizations to the reflection probe rendering setup that should smooth out any potential frame spikes.  Also fixes up some edge-case where a sphere-collider was not getting deleted properly that could result in explosions.  Please report any issues with this release as soon as possible so that they may be cleaned up for a proper release over the weekend.

[Agustin]

7 minutes ago, Shadowmage said:

 

Maybe it is too soon, but I only see the source code, not the TexturesUnlimited zip to install... are you uploading yet?

EDIT: Nevermind, the files are inside the source.. I am so noob.

Edited December 2, 2017 by Agustin

[Shadowmage]

14 minutes ago, Agustin said:

Maybe it is too soon, but I only see the source code, not the TexturesUnlimited zip to install... are you uploading yet?

EDIT: Nevermind, the files are inside the source.. I am so noob.

You were actually correct; the release had apparently not uploaded yet (or rather, it had finished, but I had it open in another tab and had forgotten to push the submit button).  Should be ready now

-- But yes, you can also use the GameData contents out of the source-zip; all the same thing in the end.

[Shadowmage]

Updated release is available:

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

Just an 'official' release of what I had packed up for the -pre a few days ago.  AVC has been updated, should be available to CKAN shortly.

[anan4art]

There's some weird missing transparency texture for Mk16 parachute every time using @Electrocutor patch in November 20^th (page 5 in this thread). The screenshot attached using ksp 1.3.1 x64 d3dx11. Current rig is a 10 years old Core2Duo paired with an nVidia GT430.

Log file https://www.dropbox.com/s/k55lj5pqw1upt98/KSP.log?dl=0

[Kaa253]

I am curious to know.
Has anyone running with any linux distro on any rig been able to get the textures to load?
https://github.com/shadowmage45/TexturesUnlimited/issues/16

 

[Shadowmage]

3 hours ago, Kaa253 said:

I am curious to know.
Has anyone running with any linux distro on any rig been able to get the textures to load?
https://github.com/shadowmage45/TexturesUnlimited/issues/16

 

That is actually a very good question.

I cannot confirm that I have had anyone running Linux report that they've been able to load it.  I do know that it works fine under various Windows(dx11/openGL), and under OSX(openGL).

As far as I know there shouldn't be any operating system level incompatibilities, but apparently there are some major problems with the linux distros not including up-to-date drivers and OpenGL problems.  You need at least OpenGL 3.2 (3.5?) support, but apparently some of the larger sources for drivers only support up to OpenGL 3.0/3.1.

Is there anyone running Linux that can confirm that TU is working for them?  Or, alternatively, is there anyone running Linux that has openGL >= 3.5 that can confirm that TU is or is not working?

[T-10a]

4 hours ago, Shadowmage said:

That is actually a very good question.

I cannot confirm that I have had anyone running Linux report that they've been able to load it.  I do know that it works fine under various Windows(dx11/openGL), and under OSX(openGL).

As far as I know there shouldn't be any operating system level incompatibilities, but apparently there are some major problems with the linux distros not including up-to-date drivers and OpenGL problems.  You need at least OpenGL 3.2 (3.5?) support, but apparently some of the larger sources for drivers only support up to OpenGL 3.0/3.1.

Is there anyone running Linux that can confirm that TU is working for them?  Or, alternatively, is there anyone running Linux that has openGL >= 3.5 that can confirm that TU is or is not working?

I found out more about openGL and Linux. Mesa on Linux has two different modes: Core, and Compatibility. Core uses the highest driver supported by the card (for me, openGL 4.5) for use in the latest games (TF2 seems to run on this mode, and cranking the visuals up gives TexturesUnlimited-style reflections on weapons/items, though muddied a bit due to it being 10 years old) and Compat uses a much older, yet stable OpenGL version (here, OpenGL 3.0). It seems KSP on Linux uses the Compat profile, so it can't use the shaders.

Edited December 4, 2017 by T-10a

[Shadowmage]

7 minutes ago, T-10a said:

I found out more about openGL and Linux. Mesa on Linux has two different modes: Core, and Compatibility. Core uses the highest driver supported by the card (for me, openGL 4.5) for use in the latest games (TF2 seems to run on this mode, and cranking the visuals up gives TexturesUnlimited-style reflections on weapons/items, though muddied a bit due to it being 10 years old) and Compat uses a much older, yet stable OpenGL version (here, OpenGL 3.0). It seems KSP on Linux uses the Compat profile, so it can't use the shaders.

Interesting, and good find.

That would seem to explain most of what has been being seen then.  I wonder why the .log files still state that the platform is using OpenGL 4.5 if it is really reverting to OpenGL 3.x?

Is there any way to force GL-Core?  (this is what the shaders are specifically targeting when compiled, because as-per the Unity docs that should be the correct setup for Linux installs)

[T-10a]

13 minutes ago, Shadowmage said:

Interesting, and good find.

That would seem to explain most of what has been being seen then.  I wonder why the .log files still state that the platform is using OpenGL 4.5 if it is really reverting to OpenGL 3.x?

Is there any way to force GL-Core?  (this is what the shaders are specifically targeting when compiled, because as-per the Unity docs that should be the correct setup for Linux installs)

To my knowledge, no. Aside from a environment variable that crashes the game on launch, the only way to force it is if Squad builds KSP to use at least the version of OpenGL needed to run TexturesUnlimited, and as KSP is closed-source there is no user end/dev way to do so. 

(disclaimer: I am a user, not a programmer. Here's the mesa website, as it probably has documentation for this sort of thing: https://www.mesa3d.org/)

Edited December 4, 2017 by T-10a

[Kaa253]

Thanks @T-10a for the extra information you have provided about mesa & OpenGL on Linux.

I have a couple of ideas to try that probably will not work if KSP_Linux is built against OpenGL 3.x. However and regardless, I will be travelling for work over the next 9 days and will not be able to try anything until I get back.

 

[Electrocutor]

Quote

OpenGL core profile command line arguments

It’s possible to start the player with OpenGL using the command line arguments:

• -force-opengl: To use the legacy OpenGL back-end
• -force-glcore: To use the new OpenGL back-end. With this argument, Unity will detect all the features the platform support to run with the best OpenGL version possible and all available OpenGL extensions
• -force-glcoreXY: XY can be 32, 33, 40, 41, 42, 43, 44 or 45; each number representing a specific version of OpenGL. If the platform doesn’t support a specific version of OpenGL, Unity will fallback to a supported version
• -force-clamped: Request that Unity doesn’t use OpenGL extensions which guarantees that multiple platforms will execute the same code path. This is an approach to test if an issue is platform specific (a driver bug for example).

Unity itself supports d3d 9-12, opengl, and vulcan; but I do not know what Squad includes in their Graphics API list for compile.

Edited December 5, 2017 by Electrocutor

[Kaa253]

37 minutes ago, Electrocutor said:

I do not know what Squad includes in their Graphics API list for compile.

A 30 second test before I leave for work confirms that -force-glcore is indeed supported by KSP_linux 64 bit and does solve the problem.

I briefly saw a set of shiny gold metallic textured tanks in the VAB    -     Awesome!

Thanks @Electrocutor 

I wonder if other graphics aspects of the game are also improved?

[Electrocutor]

Unfortunately, graphics card manufacturers horribly misrepresent their products which causes confusion. For example, a GTX 780 is listed as being DirectX12, but the reality is that it only supports 11.0; and does not support 11.1, 11.2, 11.3, 11.4, 12.0, or 12.1.

They can get away with this because the software driver supports the DirectX12 API, even if the card itself does not support any of the Direct3D 12 (or even the majority of Direct3D 11) features.

This all devolves into the mess that is DirectX vs Direct3D API vs Direct3D Feature Level vs Unified Shader Model, and is further complicated by some cards having partial support. It gets even more complicated when a previous model is revisioned to a different architecture, which leads to the same model of GPU from different times having different sets of features.

Edited December 5, 2017 by Electrocutor

[Electrocutor]

For quick reference:
The word 'force' seems like something bad, but in fact this is the officially supported way that Unity uses to select between different rendering APIs.

MacOS or Linux
-force-glcore

 

Windows

Nvidia 600, 700, 900, 1000 series:
-force-d3d11

Nvidia older than 600 series:
*Need more data; likely is a combination of -force-glcore and -force-d3d11 with -force-feature-level or -force-driver-type-warp.

 

All of my testing so far has shown that vanilla KSP does not have any graphical errors regardless of which mode you use as long as it's supported by your hardware. As mentioned earlier, you cannot trust the manufacturer's website for what your card supports. That said, there are several mods that seem to have incompatibilities with d3d11 and d3d12 resulting in failure to render, shading errors, freezing, shadow banding, etc.

*As far as I can tell, -force-vulkan is the only mode not supported by KSP. -force-d3d12 works, but is flaky (don't use it until v1.4).

Edited December 6, 2017 by Electrocutor

[Shadowmage]

3 hours ago, Electrocutor said:

For quick reference: [...snip...]

Excellent work in locating all of that information.  I likely never would have thought to have someone try to force opengl on an already 'opengl only' platform such as Linux/OSX.

 

Hmm... I wonder if I can specifically compile the shaders to target the legacy openGL API (in addition to GL-core, which is used by OSX).....