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)

[frihyland]

Well I know he tracks his thread on Bethesda boards, and he does show up here on occasion, he's not the easiest guy to track down but he always responds eventually :P The most logical site to post would be the oblivion nexus site ddsopt forum.

[Iriodus]

Well I know he tracks his thread on Bethesda boards' date=' and he does show up here on occasion, he's not the easiest guy to track down but he always responds eventually :P The most logical site to post would be the oblivion nexus site ddsopt forum.[/quote']

Is there a way to determine the filename of a particular texture in-game? Or would I have to go hunting for the offending texture in the BSA?

 

Edit: And thanks again!

[frihyland]

its pretty easy to narrow it down to either vanilla or a mod, then its more difficult to figure out which mod, and the specific texture requires a degree of technique that I have yet to fully master.  There are a large number of console commands that show a ton of information that I haven't fully explored yet. Here's a resource. And something to get you started.

 

open the console ~ and click on the texture in question if the resulting number that pops up starts with 00 its a vanilla texture if it something else its a mod.

[z929669]

@Iriodus

 

Best way to communicate bugs or issues with specific DDSopt functionality is by posting on Ethatron's DDSopt Github. Let him know that you did this on the Beth forums. Perhaps he will check there more often if people start using it to report on functionality.

 

Also, USE the 8.0 pre-release 3 and follow the instructions earlier in this thread. It is a MUCH better implementation!

 

On Github, you should provide detailed feedback, including the versions of DDSopt and affected textures.

[torminater]

So just optimized 427 mods (incl. no-texture-mods) with ddsopt... oh my god. i'll never manage to find all of the texture errors ddsopt came up with :-(

From 24.370.488.893 Bytes to 21.759.628.870 Bytes.

[LeetMiniWheat]

my skyrim folder is about 38GB lol, i'm afraid to optimize...

[z929669]

So just optimized 427 mods (incl. no-texture-mods) with ddsopt... oh my god. i'll never manage to find all of the texture errors ddsopt came up with :-(

From 24.370.488.893 Bytes to 21.759.628.870 Bytes.

I run against each of my extracted mods rather than the textures folder. then I repack my mods once I verify that there are no errors. ;)

[LeetMiniWheat]

sounds like an awful lot of work.

 

and @torminator: hope you had a backup of your skyrim install lol. i've got 3 mirror copies of my install on 3 different hard drives. (would suck to loose hundreds of hours worth of work modding it)

[torminater]

naaaw, too much work. got some serious exams comin up next week ^^

[Kelmych]

I have a few questions on using DDSopt (v80pre3) using the most recent DDSopt processing parameters from this thread based on some of the discussion in this and other threads:

 

1. With textures whose dimensions are not a power of 2 (e.g.,  Soul Gems Differ in the STEP package) should I use DDSopt or not, and if so would I process it differently?

 

2. With  textures that have 2:1 dimensions (or any non 1:1) there was a discussion in this thread in May about some issues when the lowest mipmap was removed by DDSopt. Do such textures need to be processed the same, use different processing parameters, or should they not be processed by DDSopt?

 

3. When you create the new STEP I expect there will be BAIN converters or some other mechanism for at least some files to allow getting the right textures, etc. for STEP. If I use DDSopt on each mod the way z929669 suggests (which I like at least when STEP doesn't want every texture in the mod) then I'll likely have a problem since the file sizes in the recompressed mod file won't be the same as for the original version and any BAIN converters won't work. Have you thought how you accommodate the use of DDSopt prior to adding a mod to Skyrim in the automation you are considering for simplifying installation of the next version of STEP (vs. running DDSopt on the Texture folder after the mods are already added to take care of any textures that were not already processed)?

[frihyland]

• They will be resized and stretched or shrunken as appropriate to a regular size, this will cause degradation and usually quite radical in my experience.
• I would set the parameters to avoid remipping for those particular mods.
• We are trying to move away from bcf to ahc in general, the next STEP will likely support both formats unless we fix the ahc issues very soon. Incorporating ddsopt processing into AHC is a very interesting idea and quite doable in the long term, but not for this round of STEP.

[Kelmych]

1. That's what I thought would happen in DDSopt, but I wanted to make sure. Optimizer Textures, however, says it resizes such textures. Does it use another algorithm to extend the texture vs. stretching it?

2. The newest version of DDSopt has a configuration parameter "Don't eliminate lower mip levels". I thought Ethatron added this to support DDSopt processing of non 1:1 textures, or was it for some other purpose? I was wondering whether the right way to process texture files was to use the configuration that z929669 posted for all of the 1:1 textures and then do a separate run for non 1:1 textures with the new mip level parameter checked (leaving the border related parameter unchecked)?

In the run that z929669 published June 8 on a DDSopt run with Skyrim textures (vanilla log file) there are a number of non 1:1 textures, and with the configuration parameters used in the run 1 mip level was removed from these textures. This surprised me; based on the previous discussion I thought these textures would be skipped or processed separately with DDSopt preserving the lowest mip levels. Perhaps it was the highest mip level that was removed and the lowest level was actually retained. I'm certainly not an expert on windows texture files so that's why I asked.

3. I was primarily commenting on handling files that had already run through DDSopt, but if multiple DDSopt runs are needed to handle png files and perhaps non 1:1 textures then some automation of the DDSopt runs might also be useful.

[Kelmych]

I ran a test case with the "Don't eliminate lower mip levels" parameter checked and a texture with dimension 2048:4096. All 13 mip levels were saved by DDSopt and there was no apparent difference between the input and output texture file. If the "Don't eliminate lower mip levels" parameter is unchecked one mip level is eliminated.

[z929669]

I ran a test case with the "Don't eliminate lower mip levels" parameter checked and a texture with dimension 2048:4096. All 13 mip levels were saved by DDSopt and there was no apparent difference between the input and output texture file. If the "Don't eliminate lower mip levels" parameter is unchecked one mip level is eliminated.

This is true, yes. Ethatron only added the parameter because he could. He prefers to remove the lower mip, as it reduces size. It likely does not matter at all.

[Kelmych]

Does that mean I don't have to worry about not having the lowest mip level for textures with non-1:1 dimensions? I wan't positive about the conclusion of the discussion in May about this.