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

[Ithirahad]

After updating drivers and rebuilding my install from scratch, attempting to launch with -force-glcore has spit out the same error.

 

Kerbal Space Program [version: Unity 2017.1.3p1 (02d73f71d3bd)]

nvoglv64.dll caused an Access Violation (0xc0000005)
  in module nvoglv64.dll at 0033:6da69530.

Error occurred at 2019-05-21_192154.
S:\Games\KSP RSS 1.6.1\KSP_x64.exe, run by <<USERNAME REDACTED>>.
44% memory in use.
20433 MB physical memory [11423 MB free].
40913 MB paging file [28800 MB free].
134217728 MB user address space [134211351 MB free].
Read from location 00000000 caused an access violation.

Context:
RDI:    0x00000006  RSI: 0x00000006  RAX:   0x00000005
RBX:    0x00000000  RCX: 0x0000000a  RDX:   0x75d3b6a1
RIP:    0x6da69530  RBP: 0x122dd080  SegCs: 0x00000033
EFlags: 0x00010246  RSP: 0x122ce700  SegSs: 0x0000002b
R8:    0x00000019  R9: 0x00000000  R10:   0x00000004
R11:    0x05a0c210  R12: 0x00000000  R13:   0x00000005
R14:    0x00000000  R15: 0x00001403

(I can launch into the game with DX9 or DX11/DX12, so if there's an ingame option that needs to be changed, I can access it.)

Edited May 22, 2019 by Ithirahad

[captinjoehenry]

Oh just so you know I still have BSOD when using directx 11 even after updating my graphics card driver and clearing out all old drivers I no longer need.  As it is the BSOD only happens after having KSP open for I think over 5 or so hours.  If I close and relaunch KSP it’s fine but if I have it on continually for over five hours I get a BSOD

[Shadowmage]

19 hours ago, captinjoehenry said:

 If I close and relaunch KSP it’s fine but if I have it on continually for over five hours I get a BSOD

Interesting -- that points towards the problem likely being either a memory issue (running out of ram, or writing to a bad block), a storage issue (log file size, error on drive during write operation), or thermal issues and overheating.  Normally thermal issues will manifest faster than 5 hours of continuous use, but still a possibility.  (of course, computers are insanely complex, and it could be something else entirely... but those are the points I would start on if I had those problems on my personal machine)

 

19 hours ago, Ithirahad said:

(I can launch into the game with DX9 or DX11/DX12, so if there's an ingame option that needs to be changed, I can access it.)

Thanks for the confirmation.  I'll take a look at my settings and see if I can spot what needs to be changed;  IIRC it was something regarding fullscreen/bordered/windowed modes, though I don't remember it causing that specific access violation (more it was an error regarding unsupported resolution or something).

Apparently this is also part of a 'known issue' with Unity regarding some non-standard graphics adapter settings / multiple adapters.  Not sure if that is exactly what is happening in this case, but seems like it is similar in its effect...  https://forum.unity.com/threads/unity-2018-2-7f1-windows-standalone-crash-on-first-run-unityplayer-dll-caused-an-access-violation.556585/

Apparently it is also a reported bug on the SQUAD tracker, though I've not much hope of them fixing it for Windows, as OpenGL is only officially supported on Mac and Linux -- https://bugs.kerbalspaceprogram.com/issues/20055

And one really strange solution that I found was modifying the startup command to use double-dashes (from: 

, such as: C:\Kerbal Space Program\KSP.exe" --force-glcore

 

Edited May 22, 2019 by Shadowmage

[Ithirahad]

12 minutes ago, Shadowmage said:

Apparently this is also part of a 'known issue' with Unity regarding some non-standard graphics adapter settings / multiple adapters.  Not sure if that is exactly what is happening in this case, but seems like it is similar in its effect...  https://forum.unity.com/threads/unity-2018-2-7f1-windows-standalone-crash-on-first-run-unityplayer-dll-caused-an-access-violation.556585/

Odd. In my case, in the device manager - even with hidden devices shown - the only display adapter that exists is my 1050Ti; no virtual adapters from telepresence software or anything like what was seen in that issue thread. (Also, the location that the system had attempted to read was different from all of those cases, but IDK if that can vary with system configuration or what)

Quote

Apparently it is also a reported bug on the SQUAD tracker, though I've not much hope of them fixing it for Windows, as OpenGL is only officially supported on Mac and Linux -- https://bugs.kerbalspaceprogram.com/issues/20055

Yeah, that looks to be identical to my issue.
So, is there/would it be possible for there to be some kind of fallback for DX9 that doesn't include the fancy rendering features that don't work on it, or do all the special texture setups and things in TU mods preclude this sort of feature? Looks to my (mostly) lay man's eye like DX11 and OpenGL can't necessarily be relied upon for every user. :\

Edited May 22, 2019 by Ithirahad

[captinjoehenry]

15 minutes ago, Shadowmage said:

Interesting -- that points towards the problem likely being either a memory issue (running out of ram, or writing to a bad block), a storage issue (log file size, error on drive during write operation), or thermal issues and overheating.  Normally thermal issues will manifest faster than 5 hours of continuous use, but still a possibility.  (of course, computers are insanely complex, and it could be something else entirely... but those are the points I would start on if I had those problems on

I would guess it probably has to do with the fact that I use the stutter reduction mod and shove another 4 gigs of heap space into KSP.  As it is I do have 32gb of ram but KSP uses like 16 gigs just idle with all the mods I have so I would assume it's a ram issue.  And I can have KSP running all day long as long as I close and relaunch it often enough.

[Shadowmage]

14 minutes ago, Ithirahad said:

So, is there/would it be possible for there to be some kind of fallback for DX9

No.  DX9 has terrible rendering issues that I cannot solve (no seam fixup on cubemaps, randomly swapped cubemap faces).

You -can- use it however (DX9).  I haven't blocked the mod from running on DX9.  You'll just have the 'incompatible API' warning when you start the game (which you can actually disable in one of the config files...), and of course, anything with reflections will look terrible because of the DX9 issues.

17 minutes ago, Ithirahad said:

Looks to my (mostly) lay man's eye like DX11 and OpenGL can't necessarily be relied upon for every user

Only if they have issues with their hardware/software.  If OpenGL isn't working.... you've got other problems that need to be solved (OpenGL has been supported by every major graphics card for the last ~15 years, even the terrible integrated Intel ones).  Certainly it is supported on your 1050ti (guaranteed, as that is the card I'm using on my work computer right now, and it runs KSP just fine in OpenGL mode).

Again, this would be either a software/driver or hardware issue, and is not support that I can provide.  Your OpenGL crashing issue isn't with the mod, its with your computer.

[Ithirahad]

1 hour ago, Shadowmage said:

Only if they have issues with their hardware/software.  If OpenGL isn't working.... you've got other problems that need to be solved (OpenGL has been supported by every major graphics card for the last ~15 years, even the terrible integrated Intel ones).  Certainly it is supported on your 1050ti (guaranteed, as that is the card I'm using on my work computer right now, and it runs KSP just fine in OpenGL mode).

Again, this would be either a software/driver or hardware issue, and is not support that I can provide.  Your OpenGL crashing issue isn't with the mod, its with your computer.

OpenGL itself works fine judging from everything else I've tested with it, and I'm not blaming you or your mod. This sounds more like a Unity/KSP thing. Just, a Unity/KSP thing that wouldn't necessarily have come up if I wasn't trying to get your mod to work (with everything else I'm trying to use).

Quote

You -can- use it however (DX9).  I haven't blocked the mod from running on DX9.  You'll just have the 'incompatible API' warning when you start the game (which you can actually disable in one of the config files...), and of course, anything with reflections will look terrible because of the DX9 issues.

Yeah... can reflections be globally disabled? (REFLECTION_CONFIG enabled option in general config?) If so, that's probably a sufficient workaround.

Edited May 22, 2019 by Ithirahad

[Shadowmage]

1 hour ago, Ithirahad said:

Yeah... can reflections be globally disabled? (REFLECTION_CONFIG enabled option in general config?) If so, that's probably a sufficient workaround.

Technically yes, but then any surface that is intended to be reflective will instead simply be black, which is not at all the intended look for those surfaces.

The only 'correct' way to do reflections with DX9 is to not do them at all (which unfortunately would require completely separate art assets and shaders; which is exactly what older versions of SSTU did, but was far too much overhead for me to maintain long-term).

[Ithirahad]

...Well, after quite a while more of experimentation, suddenly DX11 is magically working perfectly, but all the parts that use Textures Unlimited seem to just have no model or collision mesh, and break the editor somehow (UI becomes nonresponsive).

I assume this has to do with other mods I'm messing with, so I won't bother people on this thread any more if there isn't some obvious thing I'm missing, but I just figured I'd ask in case this is a common or known issue with a known fix. ¯\_(ツ)_/¯

Edited May 23, 2019 by Ithirahad

[Shadowmage]

14 hours ago, Ithirahad said:

...Well, after quite a while more of experimentation, suddenly DX11 is magically working perfectly, but all the parts that use Textures Unlimited seem to just have no model or collision mesh, and break the editor somehow (UI becomes nonresponsive).

I assume this has to do with other mods I'm messing with, so I won't bother people on this thread any more if there isn't some obvious thing I'm missing, but I just figured I'd ask in case this is a common or known issue with a known fix. ¯\_(ツ)_/¯

Almost certainly a mod related issue; something is throwing an exception during part/model loading.

You could try posting/uploading/linking to a copy of your KSP.log file.  Without knowing which exceptions were being caused, and from what code, all anyone can do is guess at what the actual problem is (all of that is listed in the log file).

[Ithirahad]

Well, we're in very unsupported, unknown territory, so I hardly expect any miracles here, but just in case, here you go:
LINK to log

I did notice this exception, if it is relevant:
 

[ERR 13:03:06.197] [ModuleManager] Exception while calling TexturesUnlimitedLoader.ModuleManagerPostLoad() :


[EXC 13:03:06.197] ArgumentException: An element with the same key already exists in the dictionary.
	System.Collections.Generic.Dictionary`2[System.String,KSPShaderTools.IconShaderData].Add (System.String key, KSPShaderTools.IconShaderData value)
	KSPShaderTools.TexturesUnlimitedLoader.buildShaderSets ()
	KSPShaderTools.TexturesUnlimitedLoader.load ()
	KSPShaderTools.TexturesUnlimitedLoader.ModuleManagerPostLoad ()
	System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)
	Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
	System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)
	System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters)
	ModuleManager.PostPatchLoader+<Run>d__16.MoveNext ()
	UnityEngine.Logger:Log`(Exception)
	ModuleManager.Logging.UnityLogger:Exception(String, Exception)
	ModuleManager.Logging.ModLogger:Exception(String, Exception)
	ModuleManager.<Run>d__16:MoveNext()
	UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

 

Edited May 23, 2019 by Ithirahad

[Shadowmage]

3 minutes ago, Ithirahad said:

[ERR 13:03:06.197] [ModuleManager] Exception while calling TexturesUnlimitedLoader.ModuleManagerPostLoad() : [EXC 13:03:06.197] ArgumentException: An element with the same key already exists in the dictionary. System.Collections.Generic.Dictionary`2[System.String,KSPShaderTools.IconShaderData].Add (System.String key, KSPShaderTools.IconShaderData value) KSPShaderTools.TexturesUnlimitedLoader.buildShaderSets () KSPShaderTools.TexturesUnlimitedLoader.load () KSPShaderTools.TexturesUnlimitedLoader.ModuleManagerPostLoad ()

That would do it.  If TU errors out during loading.... I wouldn't expect anything to work correctly.  The cause of that specific error is caused by an incorrect config/patch, which is specifying some duplicate values be added to a collection that does not accept duplicates.  Specifically it is happening on this patch definition:   [LOG 13:03:05.468] Loading shader icon replacement data for: SSTU/PBR/Masked :: SSTU/MaskedIcon

Further reading through your log points towards TU trying to load the following shader pack twice -- Loading Shader Pack: SSTUShaders :: S:/Games/KSP RSS 1.6.1/KSP_x64_Data/../GameData/000_TexturesUnlimited/Shaders/sstushaders-universal.ssf

Which means you have some duplicate configs somewhere specifying that shader pack to be loaded a second time (which is the error that will need to be tracked down and corrected). 

Specifically, you have an extra folder inside the 000_TexturesUnlimited/Shaders folder that needs to be removed:

'[LOG 13:03:03.205] Config(KSP_SHADER_BUNDLE) GameData/000_TexturesUnlimited/Shaders/SSTUShaders/'

Remove that folder, and if there are no other issues, TU should be able to load.  Not sure how/why/where that folder came from?  (its not in the distribution?)

[Ithirahad]

Quote

Not sure how/why/where that folder came from?  (its not in the distribution?)

It would have come from me botching my install. I think I did some sort of lazy manual reinstall over a different version that I'd tried previously trying to troubleshoot a different problem... lol. Thanks for the pointer. I'll try this.

EDIT: ...Errr, I'm not seeing any such folder in my Textures Unlimited. The only "SSTUShaders" I see is SSTUShaders.cfg - a file, not a folder. This isn't what you meant, is it?

Edited May 23, 2019 by Ithirahad

[blowfish]

15 minutes ago, Shadowmage said:

That would do it.  If TU errors out during loading.... I wouldn't expect anything to work correctly.  The cause of that specific error is caused by an incorrect config/patch, which is specifying some duplicate values be added to a collection that does not accept duplicates.  Specifically it is happening on this patch definition:   [LOG 13:03:05.468] Loading shader icon replacement data for: SSTU/PBR/Masked :: SSTU/MaskedIcon

Further reading through your log points towards TU trying to load the following shader pack twice -- Loading Shader Pack: SSTUShaders :: S:/Games/KSP RSS 1.6.1/KSP_x64_Data/../GameData/000_TexturesUnlimited/Shaders/sstushaders-universal.ssf

Which means you have some duplicate configs somewhere specifying that shader pack to be loaded a second time (which is the error that will need to be tracked down and corrected). 

Specifically, you have an extra folder inside the 000_TexturesUnlimited/Shaders folder that needs to be removed:

'[LOG 13:03:03.205] Config(KSP_SHADER_BUNDLE) GameData/000_TexturesUnlimited/Shaders/SSTUShaders/'

Remove that folder, and if there are no other issues, TU should be able to load.  Not sure how/why/where that folder came from?  (its not in the distribution?)

I've seen this too, note that it's specifically on a database reload.  I haven't really investigated much but my guess is that there's something that's already initialized that TU is trying to re-initialize without first clearing the old data out.

[Shadowmage]

3 minutes ago, blowfish said:

I've seen this too, note that it's specifically on a database reload.

Indeed -- that situation would make sense to see the error (as I'm not explicitly clearing anything prior to loading; so it would re-use existing populated collections during reload, and likely throw the same exception as seen above).

And....  issue opened on that, as it really is something that should be fixed (and not too difficult to fix at that).   https://github.com/shadowmage45/TexturesUnlimited/issues/66

Should be able to get that one fixed for the upcoming KSP 1.8 release.

[Ithirahad]

...okay, after deleting the SSTU shader config file thing, things seem to be working rendering-wise! Now I'm just getting an SSTU-part-specific issue with the editor seizing up, but that's probably due to configs not supporting the new version properly and regardless not for this topic. Thanks a lot, either way.

Edited May 23, 2019 by Ithirahad

[The Destroyer]

Well, I'm having the same issue as Chicken Nugget before. Parts appear darker than normal in the editor selection 

I'm running DX11, only other mods are texture replacer, Chatterer, camera tools, restock.

 

Wheels are very dark in particular

 

 

Edited June 1, 2019 by The Destroyer

[gap]

On 5/15/2019 at 6:35 PM, gap said:

I have recently installed this mod (v1.4.7.21) together with the unofficial stock configs by 0_0_1, and I must say that they make a huge difference ! Unlike stock game, specular reflections and other lighting effects are at their best now, and every metal part looks as shiny as it should. The reason I am writing here is saying thank you for your amazing work on this mod, but also  reporting a visual glitch that I am experiencing; in short, since I started using TU, the suspension lines of the Mk 16 parachute are connected by solid yellow triangular surfaces, forming an inverted cone when the chute is fully open.

  Reveal hidden contents

Curiously, the problem doesn't apply to all the chutes among the ones I have tested so far.  A way around to it, as far as the Kk 16 chute is concerned, is commenting the part out in the config file, but obviously that also totally removes any metallic reflection from chute's metal cover.

After playing a couple of weeks with the TU config mod that I had mentioned in my previous posts (https://spacedock.info/mod/1841/Textures Unlimited Default Stock Config - Unofficial), I must say that it causes several other visual glitches and undesired effects besides the one I had previously reported.

My question is, is there any other config mod for Texture Unlimited with better support that you can recommend? I had already asked this question, but since it remained unanswered I hope it is okay asking it again. I don't have part mods installed, so I am only concerned about stock parts

[Electrocutor]

1 hour ago, gap said:

My question is, is there any other config mod for Texture Unlimited with better support that you can recommend?

The most complete TU implementation to stock was https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/ , but was never finished. I'm unsure if he intends to come back and complete it or not.

[Electrocutor]

@Shadowmage You can add Procedural Fairings to the OP if you want.

 

[gap]

On 6/2/2019 at 3:06 AM, Electrocutor said:

The most complete TU implementation to stock was https://forum.kerbalspaceprogram.com/index.php?/topic/174188-textures-unlimited-recolour-depot/ , but was never finished. I'm unsure if he intends to come back and complete it or not.

Thank you Electroductor, I will test that mod as soon as possible!

[Gordon Dry]

@Shadowmage I tried to edit the parts of Fintech Industries to always have "recolorable = true" but this only changed that the word "Recolorable" appeared inside the switcher UI in the PAW:

It did not add the button to open the recolor UI.

Could this be because the parts use KSPTextureSwitch and not ModulePartVariants ?

[Shadowmage]

Just now, Gordon Dry said:

Could this be because the parts use KSPTextureSwitch

TU only works with KSPTextureSwitch.

The issue is that in order to support recoloring the textures have to be authored for recoloring from the start.  Those parts were not created for recoloring, and thus to get it working, you would have to redo the textures.  No other way around it.

^^^ is why there is not a functional (and properly implemented) TU patch/recoloring mod for stock -- nobody wants to redo all those terrible stock textures.

[Gordon Dry]

Well, I like the reply, but not the fact

[Shadowmage]

55 minutes ago, Gordon Dry said:

Well, I like the reply, but not the fact

Understood, and fully appreciated.

Its one large bit about TU that I've never been fond of; but also never found any good solutions.  There are partial solutions available with the use of the new 'normalized' recoloring setup, so that for some basic recoloring setups all that would need to be provided would be the recoloring mask textures, but even that system has its issues with specific inputs.  There might be a system to allow for arbitrary recoloring of any textures, but I certainly haven't found it, seen it, or heard of it anywhere.

-----

For a long time now I've really wanted to do a complete TU pack for stock parts.  But its so much work, and the source textures aren't that great to begin with.  My next hope was to create a pack for Restock (as I love the detail and unified looks), but its assets were released as ARR and so are off limits (and would still be a ton of work, but at least with a good source).