GUIDE [WIP] DDSopt & Texture Overhauls

[z929669]

Discussion thread:
DDSopt Guide by STEP
Wiki Link

---

 

GET DDSopt:
Github Pre-release versions
Official Nexus versions (select pre-release update 4)

[Kelmych]

The initial version of the updated Mod Optimization portion of the DDSopt guide is now available. The purpose is to allow users to decide which STEP mods to process with DDSopt. This version has, for each STEP mod that contains textures:

- indicators on whether DDSopt provided noticeable improvements in the textures

- the maximum resolution of the textures in the mod.

 

More details are in the introductory portion.

This information could be and would be best placed on the DDSopt Guide as a tab. Of course, disregard if you're planning on doing that after getting it more updated.

It is a part of the DDSopt guide accessible on the DDS Optimization tab. I mentioned it here because z and I were not sure that others knew this had been added to the DDSopt guide.

[TechAngel85]

 

The initial version of the updated Mod Optimization portion of the DDSopt guide is now available. The purpose is to allow users to decide which STEP mods to process with DDSopt. This version has, for each STEP mod that contains textures:

- indicators on whether DDSopt provided noticeable improvements in the textures

- the maximum resolution of the textures in the mod.

 

More details are in the introductory portion.

This information could be and would be best placed on the DDSopt Guide as a tab. Of course, disregard if you're planning on doing that after getting it more updated.

It is a part of the DDSopt guide accessible on the DDS Optimization tab. I mentioned it here because z and I were not sure that others knew this had been added to the DDSopt guide.

I had no idea it was there. Why not add it in as a tab after the optimization tab? That'll streamline the guide and not force users to go back and forth between that page and the actual guide for instructions and everything else. Doesn't make any sense to separate the information to multiple pages when it can all be include right there in the guide via a tab. Just my 2 cents.

[Kelmych]

I had no idea it was there. Why not add it in as a tab after the optimization tab? That'll streamline the guide and not force users to go back and forth between that page and the actual guide for instructions and everything else. Doesn't make any sense to separate the information to multiple pages when it can all be include right there in the guide via a tab. Just my 2 cents.

When I started writing it we wanted to see it before deciding where to put it, and z provided a pointer in an existing page in the DDSopt guide to be able to access it. Now that it is reasonably complete I agree it should be a new tab on the DDSopt guide. I'll do so as I help z with improving the guide.

[Kelmych]

I did some further investigation on the problem with all of the black textures on the various gradient textures that have been mentioned recently. I went through the DDSopt output for the overall textures/effects/gradients directory and found that a large percentage of the textures seem to have a corrupted primary layer when processed using the DDSopt prerelease from Nexus (I tried both updates 2 and 3); the alpha layer seems to be fine. I also ran the same textures through DDSopt v080pre5b. I did not see any problems with the textures when optimized using this version of DDSopt. I suspect there might be a small code bug in the newer version causing this.

[geeee785]

Hey when trying to use 0.8 I get an error that msvcp110.dll is missing from my computer. I don't receive that same error when using 0.7.3. Anybody else have this problem and if so has anyone been able to solve it as, I am having trouble locating this file

[Besidilo]

Hey when trying to use 0.8 I get an error that msvcp110.dll is missing from my computer. I don't receive that same error when using 0.7.3. Anybody else have this problem and if so has anyone been able to solve it as' date=' I am having trouble locating this file[/quote']

https://www.microsoft.com/visualstudio/eng/downloads

[z929669]

I did some further investigation on the problem with all of the black textures on the various gradient textures that have been mentioned recently. I went through the DDSopt output for the overall textures/effects/gradients directory and found that a large percentage of the textures seem to have a corrupted primary layer when processed using the DDSopt prerelease from Nexus (I tried both updates 2 and 3); the alpha layer seems to be fine. I also ran the same textures through DDSopt v080pre5b. I did not see any problems with the textures when optimized using this version of DDSopt. I suspect there might be a small code bug in the newer version causing this.

Ethatron basically said that this is a tradeoff for correcting certain other issues with Pre5b. We will need to note these custom textures (that incidentally don't obey the unsaid "rules" I think), and list them in the INI. Ethatron said it is all about looking at the alpha channel.

[Kelmych]

I did some further investigation on the problem with all of the black textures on the various gradient textures that have been mentioned recently. I went through the DDSopt output for the overall textures/effects/gradients directory and found that a large percentage of the textures seem to have a corrupted primary layer when processed using the DDSopt prerelease from Nexus (I tried both updates 2 and 3); the alpha layer seems to be fine. I also ran the same textures through DDSopt v080pre5b. I did not see any problems with the textures when optimized using this version of DDSopt. I suspect there might be a small code bug in the newer version causing this.

Ethatron basically said that this is a tradeoff for correcting certain other issues with Pre5b. We will need to note these custom textures (that incidentally don't obey the unsaid "rules" I think), and list them in the INI. Ethatron said it is all about looking at the alpha channel.

There seem to be enough of these problems in the gradients directory that an alternate approach would be to suggest overwriting the contents of the effects/gradients directory in the DDSopt output with either the equivalent files from the gradients directory in the vanilla textures (similar to what is done for the .png files in the books directory as described in the DDSopt guide) or, for more adventuresome users, equivalent files from just the gradients directory in an optimization using pre5b (the latter is the approach I'm using). I don't want to lose the many DDSopt improvements that are present in DDSopt prelease update 3 (vs. v080pre5b), and this seems like a useful way to do so at least for now especially since there are code tradeoffs involved.

[z929669]

 

I did some further investigation on the problem with all of the black textures on the various gradient textures that have been mentioned recently. I went through the DDSopt output for the overall textures/effects/gradients directory and found that a large percentage of the textures seem to have a corrupted primary layer when processed using the DDSopt prerelease from Nexus (I tried both updates 2 and 3); the alpha layer seems to be fine. I also ran the same textures through DDSopt v080pre5b. I did not see any problems with the textures when optimized using this version of DDSopt. I suspect there might be a small code bug in the newer version causing this.

Ethatron basically said that this is a tradeoff for correcting certain other issues with Pre5b. We will need to note these custom textures (that incidentally don't obey the unsaid "rules" I think), and list them in the INI. Ethatron said it is all about looking at the alpha channel.

There seem to be enough of these problems in the gradients directory that an alternate approach would be to suggest overwriting the contents of the effects/gradients directory in the DDSopt output with either the equivalent files from the gradients directory in the vanilla textures (similar to what is done for the .png files in the books directory as described in the DDSopt guide) or, for more adventuresome users, equivalent files from just the gradients directory in an optimization using pre5b (the latter is the approach I'm using). I don't want to lose the many DDSopt improvements that are present in DDSopt prelease update 3 (vs. v080pre5b), and this seems like a useful way to do so at least for now especially since there are code tradeoffs involved.

The most efficient way to handle it would be to place the list in the INI (even for long lists). This way they all get processed, but according to the special instructions associated with the INI exceptions. Now if there are specific settings that could be selected using the GUI config that correspond to the INI categories (it seems like there are, but I don't know the exact mapping), then using the filter and parsing into separate runs would work well.

 

INI sounds best though, as this requires no special instructions. Just the per-assembled INI.

[Besidilo]

Here's what I did:

 

1) Extracted all vanilla + HRDLC textures using BSAopt to separate folders.

2) Followed Z's instructions for fixing HRDLC.

3) Merged the fixed HRDLC textures with vanilla textures.

4) Ran DDSopt v8 on ALL textures using the Recommended settings from the OP.

5) Overwritten the incorrectly optimised textures from the DDSopt guide and Neo's guide with the unoptimised textures from the vanilla folder.

6) Archived using LZMA2 Ultra compression that gets the textures down to something like 3.1 GB (from 5.65 GB).

7) Disabled HRDLC from loading in Data Files.

 

This pretty much gives you a base that won't change any time soon, unless Bethesda updates their textures for some reason.

[z929669]

Here's what I did:

 

1) Extracted all vanilla + HRDLC textures using BSAopt to separate folders.

2) Followed Z's instructions for fixing HRDLC.

3) Merged the fixed HRDLC textures with vanilla textures.

4) Ran DDSopt v8 on ALL textures using the Recommended settings from the OP.

5) Overwritten the incorrectly optimised textures from the DDSopt guide and Neo's guide with the unoptimised textures from the vanilla folder.

6) Archived using LZMA2 Ultra compression that gets the textures down to something like 3.1 GB (from 5.65 GB).

7) Disabled HRDLC from loading in Data Files.

 

This pretty much gives you a base that won't change any time soon, unless Bethesda updates their textures for some reason.

The only thing I would qualify is that, for Wrye Bash users, when packing up into the archive, use non-solid compression. This may slightly decrease the compression ratio, but the benefit is huge when you are (un)installing upstream packages, re-unpacking from the huge vanilla archive ... extraction goes much faster.

[stoppingby4now]

Here's what I did:

 

1) Extracted all vanilla + HRDLC textures using BSAopt to separate folders.

2) Followed Z's instructions for fixing HRDLC.

3) Merged the fixed HRDLC textures with vanilla textures.

4) Ran DDSopt v8 on ALL textures using the Recommended settings from the OP.

5) Overwritten the incorrectly optimised textures from the DDSopt guide and Neo's guide with the unoptimised textures from the vanilla folder.

6) Archived using LZMA2 Ultra compression that gets the textures down to something like 3.1 GB (from 5.65 GB).

7) Disabled HRDLC from loading in Data Files.

 

This pretty much gives you a base that won't change any time soon, unless Bethesda updates their textures for some reason.

The only thing I would qualify is that, for Wrye Bash users, when packing up into the archive, use non-solid compression. This may slightly decrease the compression ratio, but the benefit is huge when you are (un)installing upstream packages, re-unpacking from the huge vanilla archive ... extraction goes much faster.

If this isn't in the WB guide, it needs to be. I'll re-archive mods even with no changes for this very reason.

[Kelmych]

 

Here's what I did:

 

1) Extracted all vanilla + HRDLC textures using BSAopt to separate folders.

2) Followed Z's instructions for fixing HRDLC.

3) Merged the fixed HRDLC textures with vanilla textures.

4) Ran DDSopt v8 on ALL textures using the Recommended settings from the OP.

5) Overwritten the incorrectly optimised textures from the DDSopt guide and Neo's guide with the unoptimised textures from the vanilla folder.

6) Archived using LZMA2 Ultra compression that gets the textures down to something like 3.1 GB (from 5.65 GB).

7) Disabled HRDLC from loading in Data Files.

 

This pretty much gives you a base that won't change any time soon, unless Bethesda updates their textures for some reason.

The only thing I would qualify is that, for Wrye Bash users, when packing up into the archive, use non-solid compression. This may slightly decrease the compression ratio, but the benefit is huge when you are (un)installing upstream packages, re-unpacking from the huge vanilla archive ... extraction goes much faster.

If this isn't in the WB guide, it needs to be. I'll re-archive mods even with no changes for this very reason.

Steps 1-4 are in the revised (as of today) DDSopt guide. We are still discussing how to handle the incorrect textures mentioned in step 5; z and Ethatron prefer to handle this via the ddsopt.ini file. Does STEP want to recommend specific compression to use for Skyrim files as in step 6? If so some users might appreciate it especially if we provide some rationale and perhaps a few quantitative comparisons with representative Skyrim data. Should step 7 be in WB guide or the installation guide?

 

By the way, now that a number of corrections have been made (and are ongoing) to the DDSOpt guide, there are a couple of inconsistencies in the Skyrim Installation guide in the part that mentions the HR DLC.

[Neovalen]

I would consider compressing it to be an optional step. If your using something like MO you wouldn't compress it. I would think a custom ini file is the route to go between Ethatron's updates.

[z929669]

I would consider compressing it to be an optional step. If your using something like MO you wouldn't compress it. I would think a custom ini file is the route to go between Ethatron's updates.

True, but WB needs compressed files so that it does not have to scan an entire directory each load. It scans the archive once and then uses the CRC to verify subsequently. I assume that this may be why MO ?duplicates? packages?

 

Compression is not really optional for WB