Missing (black/purple) Texture? Report it here!

[Farlo]

Most missing texture issues are fairly simple to fix once the culprit is found, so lets conglomerate the issue into one thread.  Any new threads about missing textures will be merged into this one.

[Kelmych]

It seems the DDSopt Wiki process has changed a little since my OP and I have not optimized under the new procedure. Allow me a moment, and I will setup a pristine vanilla Skyrim (no ENB)/DLC/UOP environment, run the current DDSopt Wiki Guide, and report back. I'll keep my current DDSopt Working directory tree for comparison.

The descriptions of the process have changed to try and make them clearer, but the processes themselves haven't really changed. Recommendations for Constraint menu settings have been edited a bit so the default values don't change very many textures, but most of the changes don't affect any textures in the vanilla set of uncompressed textures. The current recommendations would still produce the same texture you are using (1Kx1K uncompressed texture). If that isn't the best choice the recommendations can be changed once we have enough information to do so. For users with enough VRAM, 2Kx2K for a model space normal map is likely better.

[Searcher7]

 

It seems the DDSopt Wiki process has changed a little since my OP and I have not optimized under the new procedure. Allow me a moment, and I will setup a pristine vanilla Skyrim (no ENB)/DLC/UOP environment, run the current DDSopt Wiki Guide, and report back. I'll keep my current DDSopt Working directory tree for comparison.

The descriptions of the process have changed to try and make them clearer, but the processes themselves haven't really changed. Recommendations for Constraint menu settings have been edited a bit so the default values don't change very many textures, but most of the changes don't affect any textures in the vanilla set of uncompressed textures. The current recommendations would still produce the same texture you are using (1Kx1K uncompressed texture). If that isn't the best choice the recommendations can be changed once we have enough information to do so. For users with enough VRAM, 2Kx2K for a model space normal map is likely better.

 

Okay. Remember, I have an ulterior motive; to get as many textures as possible into my ramdisk. I only stumbled upon this issue by trying to reduce as many texture resolutions as possible, while trying to retain as much texture "quality" as possible via the DDSopt guide. Certainly, I will modify the process to retain "critical" textures at max resolution. I just had no idea which textures were "critical" when I started. Learning curve thing.

 

However, it seems I managed to produce a broken texture my first time through (see reply to Aiyen). I'm gonna try it again and see if I get the same result. Thanks a lot for sticking with me through this, I appreciate it.

[Kelmych]

The recommendation changes were made to avoid potential problems for many of the users, not to discourage people from using more aggressive optimization parameters. There is limited information on the effect of optimization on body-related textures since these are not the typical focus of the STEP guide, and many of the users of SR:LE which does use some alternative body textures have fairly powerful systems and don't always need much texture size reduction especially with the advent of ENBoost and Skyrim Memory patch.

[Searcher7]

DDSopt II - In Search of Normality

Used:

DDSopt.ini (1/17/2014)

v2.63 batch files

Current Wiki Guide

 

Everything was optimal (1); no errors, counts okay, etc.

Performed the Vanilla Uncompressed Textures optimization at S3 (1024x1024). SAME issue with malebody_1_msn.dds: "Black" in-game skin textures, totally transparent image in GIMP.

 

Surmised that most users were probably more interested in Quality than Performance. Re-optimized Vanilla Uncompressed Textures to a test directory using S3 Constraints, but selected 2048x2048. (H3, I guess) Don't know if that just did a pass-through or actually processed and saved the texture. It works fine in-game and looks like a common normal map in GIMP. Something about reducing max resolution breaks the texture on my machine. As an aside, pulling up the uncompressed texture in DDSopt by dbl-clicking in the Browser tab and trying to save from the Preview tab using R8G8B8 1:1 at 1024x1024 (same as the S3 Constraints tab settings) results in a Failed to Convert Texture error.

 

EDIT: I pulled up the optimized HRDLC3 texture in an ancient Compressonator. It loads okay, shows as an ARGB8888 (with Alpha) file, and is totally blank. (Just checking the GIMP plug-in.) The Extracted texture pulls up fine as RGB8888 (no Alpha).

 

(1)Wiki Guide--> "Using DDSopt" section: Main Menu Settings-->Settings-->"Write Logfile" is selected.

"Vanilla Texture Preparation" section: "Working Folder Screenshot" - file counts do not include 7 log files which were written to my Vanilla Extracted directory. Actual file count of Working and Vanilla Extracted directories is 77,123 vice 77,116 as shown in screenshot. May be confusing for new users.

[HeavensRejected]

I'm having the exact same issue with the malebody_1_msn.dds

 

I'm currently going through all the textures to see if anything else broke.

 

I've also used the S3 Uncompressed Texture Constraints.

 

It outputs a 5462 KB file which seems completely transparent resulting in a semi transparent male body.

 

After a quick test I've found something:

 

- R8G8B8 Lossless + 1024*1024 = Broken texture

- R8G8B8 Lossless + 2048*2048 = Normal texture (no conversion I guess?)

- R5G6B5 Lossy + 1024*1024 = Normal texture

- Any other combination I tried that seemed "normal"

 

So I guess the issue seems to be reducing the resolution while keeping the normal compression.

 

The same also happens to the femalebody_1_msn.dds but that gets replaced by Xenius' Mod.

Those two textures are the only ones actually getting resized.

 

I haven't looked at all the STEP mods yet but the reason this doesn't really come up here might be because another mod is overwriting the vanilla texture?

 

I've "fixed" the issue by replacing the file with the vanilla uncompressed file.

 

Hope that helped :)

[Aiyen]

Nice detailed info, thanks for that.

 

 

But really we should just write with big red letters.... DO NOT TOUCH THE SKIN TEXTURE FILES AT ALL!

 

hehe 

 

They are just so sensitive to both resolution and compression technique, and I found that the result varies a bit from time to time. 

Also most setups would not hurt from having a 2-4 detailed textures even with 1Gb of VRAM. 

[Kelmych]

Thanks for looking at this in detail. Did you try using R5G6B5 at 2048x2048? If that works properly we can recommend using that option, or suggest leaving it at 2kx2k lossless. Converting normal maps to compressed causes noticeable quality loss.

[Kelmych]

Nice detailed info, thanks for that.

 

 

But really we should just write with big red letters.... DO NOT TOUCH THE SKIN TEXTURE FILES AT ALL!

 

hehe 

 

They are just so sensitive to both resolution and compression technique, and I found that the result varies a bit from time to time. 

Also most setups would not hurt from having a 2-4 detailed textures even with 1Gb of VRAM. 

That seems a little extreme. The guide mentions that these need to be treated carefully, and the batch files separate these body-related textures (even the compressed textures) from other textures so they can receive special treatment. We can certainly strengthen the comments about optimizing these textures in the guide.

 

The current batch files for optimizing the vanilla textures prevent any of the uncompressed body-related (and terrain folder) textures from being changed except for a few model space normal space normal maps including the one that causes problems. If it doesn't cause problems for lower end systems the batch file can be changed to eliminate changing these also; there is only one large uncompressed MSN in the vanilla textures and this is it.

[Aiyen]

Hehe yeah it was more a joke then meant in all seriousness.

 

However it is vital to say to people that unless you actually know what you are doing those textures are just best left alone as the author has made them. There is no harm in letting the skin textures being large files, since most of the time the visual benefit is quite noticeable since it is a texture you are going to be seeing up close and personal most of the time during the game.

[Kelmych]

I expected so; I thought a more deadpan response to your comment would be interesting. I will change the batch file tonight.

[HeavensRejected]

Thanks for looking at this in detail. Did you try using R5G6B5 at 2048x2048? If that works properly we can recommend using that option' date=' or suggest leaving it at 2kx2k lossless. Converting normal maps to compressed causes noticeable quality loss.[/quote']

Using R5G6B5 @ 2048 shaves off around 6 MB on each file.

 

While not accurate I've uploaded two pictures of the DDS file converted into JPEG (1.8mb for faster upload):

 

Lossy (R5G6B5)

Lossless (R8G8B8)

 

The highlights (white) and shadows (dark) do change by converting it into a lossy compression (exagerated by converting it into JPEG, the actual degradation is about half)

 

I've also tried both ingame but I didn't see any major quality loss when going from lossless to lossy.

Also there are only a few occasions where you actually see the effects of the texture:

 

- First person sleeveless armor (arms only, other textures are overwritten by XCE)

- Third person sleeveless armor (arms only, other textures are overwritten by XCE)

- Third person not wearing armor 

 

And to see any difference to have to be so close that the texture itself will get blurry.

 

I don't know how big the impact on VRAM is by keeping those two files at HRDLC level compared to a compressed version but I guess it would be safe to change the batch file to just move those two files unchanged into optimized in order to keep things simple. Maybe add an advanced step for more experienced users to just optimize those two files alone if needed.

 

As for the overall savings from compressing the normal maps, most of the savings come from "empty" 257 KB files (completely "green" normals) to 1*1 sized 1 KB files.

(eg. dlc2apochryphaworld contains 90%+ useless normal maps reducing the size from 220ish MB to a mere 5 MB)

Although as I said I have no idea how much impact an often used (ever male character uses malebody_1_msn.dds I guess?) has on total VRAM load.

 

Edit: on a side note, is there even a reason to keep the other quality settings at all?

The other (V and H) settings only change the maximum texture resolution which is never beyond 2048*2048 (1024*256 respectively for a few object normals) anyway?

[Kelmych]

Thanks for looking at this in detail. Did you try using R5G6B5 at 2048x2048? If that works properly we can recommend using that option' date=' or suggest leaving it at 2kx2k lossless. Converting normal maps to compressed causes noticeable quality loss.[/quote']

 

 

I don't know how big the impact on VRAM is by keeping those two files at HRDLC level compared to a compressed version but I guess it would be safe to change the batch file to just move those two files unchanged into optimized in order to keep things simple. Maybe add an advanced step for more experienced users to just optimize those two files alone if needed.

 

The batch file was changed to copy the uncompressed HRDLC2 model space normal maps to the output folder so they are unchanged. If someone wants to modify them there will be a note in the guide about this.

 

As for the overall savings from compressing the normal maps' date=' most of the savings come from "empty" 257 KB files (completely "green" normals) to 1*1 sized 1 KB files.

(eg. dlc2apochryphaworld contains 90%+ useless normal maps reducing the size from 220ish MB to a mere 5 MB)

Although as I said I have no idea how much impact an often used (ever male character uses malebody_1_msn.dds I guess?) has on total VRAM load.

 

Edit: on a side note, is there even a reason to keep the other quality settings at all?

The other (V and H) settings only change the maximum texture resolution which is never beyond 2048*2048 (1024*256 respectively for a few object normals) anyway?

There might not be a real need for this with the vanilla textures. Low ends systems use the Hi-Res DLC Optimized replacement textures instead of the HRDLC so there aren't many textures that would be reduced in size when optimizing. It would likely ge good to remove these to simplify the vanilla texture processing portion of the guide.[/quote']

[Searcher7]

I carried on with my ramdisk mounted, bsa'd, "S" level DDSopt'd Vanilla + HRDLC with ONLY the malebody texture replaced with the original. Haven't found any other texture issues yet, but haven't been everywhere.

 

I have to say, the game looks and plays really well on my lower end machine. After Sheson's Mem Patch 3, I installed most of a CORE (performance) STEP, along with CoT and a personally edited default ENB for shadow fixes and darker nights, all without a single (knock-on-wood) CTD, freeze, or ILS in dozens of play hours.

 

The "S" level optimization improved FPS and game "responsiveness" with little visual degradation. I know that "responsiveness" is totally subjective. My machine chugs along at only 35-40 average FPS, but it is a very smooth, stutter free experience with quick mouse response now. NEVER thought I would get to this point of looks and responsiveness in Skyrim with my budget gaming systems. STEP is a major reason that I was able to accomplish this. Two years in Skyrim and I'm enjoying the game now more than ever.

[peppergomez]

I am getting a lot of purple and black textures in the game, mostly on clothing, faces, animals, and sometimes rugs. It's mostly indoors, in fact only rarely have I noticed a missing texture outdoors.

Thing is, this doesn't happen all the time on the same objects. In one game load they might have missign textures, then if I reload that same level the next day, the textures might be appearing.

 

I'm not sure what is up with this, and of the best way to troubleshoot and fix this.

 

Some background:

 

Last fall I completed the preliminary steps of Skyrim Revisited install, all the way through

3.7 Clean The Bethesda ESMs3.8 Optimizing The Bethesda Textures

Due to the complexity of the Revisited install, and to how busy I was, I didn't feel I was able to complete the full install, since it's very complicated to do.

I was pretty sure though that I had properly cleaned the ESMs and optimized the Bethesda textures. A member of this community offered to complete the remainder of the Skyrim Revisited install for me, and did so, sending me a drive with all the files, the profile, patches created, etc.

Long story short--- it didn't really work that well. Great frame rates in all areas but constant crashing outside and when loading new areas. He thought that there might be an issue with the Realstic Lighting Overhaul, so when I disable that mod and its patch, the game runs much much better.

There are however the missing textures, which BTW also would be missing when the Realistic Lighting Overhaul was present.

He thinks that the missing textures are due to my having improperly doing the DDS optimize procedure, which is entirley possible, even though I follwed the instructions to the letter, at least I think I did.

 

 

 

Can anyone help me out here, in terms of what I can do fix this problem of missing textures? Thanks.

[Kelmych]

I've not heard of problems with textures changing when reloading unless a mod like Automatic Variants is used that intentionally changes textures on creatures and/or NPCs. The original Skyrim Revisited included several mods that provided this behavior. The Skyrim Immersive Creatures mod in SR:LE does this. It's possible you have some remnants of one of these mods in your save game; these mods use a lot of scripts.

There is a new tool called MFG console that can help find the cause of purple textures. The thread I linked to has some discussion of the tool and the pointer to the mod on Nexus.

I'd be very surprised if the problem you describe is related to using DDSopt.