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]

2. install everything; use the batch file for mods to sort all textures; optimize according to guide; overwrite datafiles; reinstall every mod marked with "DDSopt recommended: no" using BAIN (so the install order is maintained and the optimized textures get replaced with the originals).

I don't really understand #2. You seem to be saying optimize all the texture files in Skyrim\Data\textures (which would take a very long time with DDSopt and optimizes many textures which shouldn't be optimized)' date=' then remove all the textures that shouldn't be optimized by reinstalling the original versions of the mods.[/quote']

That's exactly what I proposed to do.

As we said, this isn't what we recommend. Personally I don't see any advantages and I see a lot of disadvantages.

Among other issues' date=' this will cause significant problems with the vanilla textures which are separately optimized.[/quote']

I already optimized the separately so I could just reinstall them as well.

It will also be tedious since Wrye Bash won't allow two versions of a mod with the same file name' date=' and if the names are different I don't see how WB maintains the proper installation order.[/quote']

I'm not sure I'm getting what you are trying to say here. I'm not planning to manipulate anything in the bash installers folder. Just optimize, then copy the optimized textures and replace those in the datafiles folder. I doubt Wrye Bash checks for file sizes and datestamps of .dds files, so it shouldn't notice anything has changed.

Wrye Bash does keep track of at least some sizes and/or checksums, so if you use your approach you will likely need to anneal the mods to get the corrected textures installed.

I also don't see how it can work in a maintenance mode when updates to mods' date=' removal of mods, and new mods are periodically being added.[/quote']

Yes, the method would have to be repeated every time anything changes. It is totally unsuited if you plan to change your mods periodically. But I'm still hoping I can install baseline STEP, a lighting solution and Requiem and then just play the game. I spend too much time with modding the previous TES games and ended up never really playing them.

[z929669]

Regarding Wrye Bash and altering files it has installed ... not a good idea. WB will flag the installers that have files that do not CRC match with those in Bash Installers. Annealing wil effectively revert the changes, so it is always best to extract, optimize and repackage the installer. Save both original and optimized and append "-opt" to the altered package name. Place adjacent to one another by Order in the Installers tab of WB (highlight the two packages and move them together). Then install both packages. the higher in the Order will win and you can test in game. Then uninstall the higher one and test again (this will be the lower one in testing).

[Kelmych]

With the approach that Spock discussed optimization is done on the entire Data\textures directory. WB will then flag every mod that had any optimized textures. With Spock's approach mods that should not be optimized are reloaded with WB. But WB will be still have flags on any mod that was optimized since the textures in Data\textures won't match the files in the version of the mod that WB loaded.

[Spock]

That's unfortunate, I thought I found a good way of circumventing the work involved in optimizing each mod individually.

I can't help it, I'm lazy ;)

[Kelmych]

The purpose of the new batch files is to allow optimizing a set of mods at the same time, so it significantly reduces the amount of work needed. They need to then be individually loaded with WB or MO, but they needed to be individually loaded prior to optimization with the other approach. We too are trying to find more efficient ways of loading and optimizing STEP mods.

[mothergoose729]

Is there a presedence for dds causing any kind of instability? I have wrecked several mod installs by over optimizing over the last two weeks. I am not 100 percent certain that optimized textures caused my in game instability, but when you have done it a few times as I have you start to see patterns. I have settled on a group of textures now that appears to be very stable, and I have forgon oprimizng to get this far. This is after starting over many times because mysterious ctds would persist no matter what i did. In one memorable case i mass resized all textures to 1024, cutting my texture folder size in half. I had to remove my texture folder completely and start over, because even with all esps disabled i was getting frequent ctds. My theory right now is that some special kinds of textures, such as effects in the HDDLC and water textures sont respond well to optimization, but I have no proof of it.

[deathneko11]

quick little fun fact:

 

If you want to see a purple Skyrim, try extracting your textures bsa and optimizing them. Fun stuff happens :p

[EssArrBee]

Over doing anything will cause issues with this game. Stick to the directions of Kelmych for doing the vanilla textures and maybe the STEP mods, but don't do much more. You are trying to optimize your way to the perfect setup and that isn't going to happen.

 

I see it all the time that people are constantly tweaking until perfect stability is achieved and they always end up with worse stability. Just remember to KISS.

[deathneko11]

Keep it simple silly is a wondrous catchphrase!

[Kelmych]

Many people on the STEP forums have optimized the vanilla textures without having any problems. We didn't create the current vanilla optimization batch files until there had been many reports of manually performing this optimization without issues, and after creating them several forum participants used them to optimize the vanilla textures and did some detailed surveys in the game to see if there were any purple textures, etc.

 

The only reported issue is with "collapsed' textures yielding purple textures. DDSopt "collapses" single color textures with no alpha channel into a single 1x1 texture to reduce texture file size and associated VRAM use. DirectX supports textures that are collapsed, and the Skyrim game engine doesn't have any problem with these. Graphics cards that support DirextX are supposed to handle these correctly. There are apparently a few graphics cards that don't handle these properly; so far there have been two user reports of problem with these. If you think this is a problem you can always overwrite the collapsed optimized textures with the associated original textures. Almost all of the collapsed textures are in the textures\terrain folder.

 

Discussions of stability are one of the main topics on these forums since it is an especially complex situation and while there are some guidelines on avoiding stability problems there is no simple answer. I suggest posting on one of the Support and Troubleshooting threads that discuss stability. Mods with scripts and dynamic textures to create interesting effects are one of the most commonly discussed topics in these forum posts since effects increase the likelihood of stability problems.

[Spock]

With the approach that Spock discussed optimization is done on the entire Data\textures directory. WB will then flag every mod that had any optimized textures. With Spock's approach mods that should not be optimized are reloaded with WB. But WB will be still have flags on any mod that was optimized since the textures in Data\textures won't match the files in the version of the mod that WB loaded.

Would this be any problem? I mean if I got mod x and y, y being lower in the installers order overwriting stuff from x. If I now optimize x and y, WB flagging both and then reinstall x, will the conflicting, optimized textures of y get overwritten?

 

The best way would be if you had a function in wrye bash to repack textures from a mod into the archive overwriting files in the archive.

[Kelmych]

With the approach that Spock discussed optimization is done on the entire Data\textures directory. WB will then flag every mod that had any optimized textures. With Spock's approach mods that should not be optimized are reloaded with WB. But WB will be still have flags on any mod that was optimized since the textures in Data\textures won't match the files in the version of the mod that WB loaded.

Would this be any problem? I mean if I got mod x and y, y being lower in the installers order overwriting stuff from x. If I now optimize x and y, WB flagging both and then reinstall x, will the conflicting, optimized textures of y get overwritten?

They shouldn't be overwritten

 

The best way would be if you had a function in wrye bash to repack textures from a mod into the archive overwriting files in the archive.

When TES5Edit cleans a plugin WB will flag the mod since the plugin has changed. When this happens I open the mod archive file in Bash Installers and copy the revised plugin into the archive file. You could potentially do the same for the revised textures if you have a copy of the textures for the individual mod, or you could overwrite the mod in Bash Installers with a revised version that has optimized textures. This does require that the optimized textures for the mod are in a single folder and there are no textures from other mods in that folder, or that you have some other way to isolate the textures so they are only those from a single mod.

[Spock]

When TES5Edit cleans a plugin WB will flag the mod since the plugin has changed. When this happens I open the mod archive file in Bash Installers and copy the revised plugin into the archive file. You could potentially do the same for the revised textures if you have a copy of the textures for the individual mod' date=' or you could overwrite the mod in Bash Installers with a revised version that has optimized textures. This does require that the optimized textures for the mod are in a single folder and there are no textures from other mods in that folder, or that you have some other way to isolate the textures so they are only those from a single mod.[/quote']

Sadly that wouldn't work because all the textures from all the mods would be mixed in the data folder.

But if Wrye Bash does not overwrite the files even if they had been changed my method could still work if I don't do anything in the Installers tab after doing it. I could just ignore the Wrye Bash flags. Maybe I will try it after finishing my install and see if it produces any problems (could take quite a while, I would like to use Requiem with baseline STEP but I'm not familiar with how Skyrim handles conflicts, seems more complicated then older TES titles).

[menmaatre]

Hi

 

I  have a question about DDSopt. I'm near the end but something doesnt seem to match up in the last part from:

https://wiki.step-project.com/Guide:DDSop...timization

 

It says in step 6 of the optimizing section: "When this processing is complete, using the same procedure choose Vanilla Uncompressed Textures/ as the current source in the upper window of the Browser Tab and again Vanilla Optimized/ remains as the current destination (lower window). The DDSopt Browser Tab will then look like Figure B3."

 

Then it says in step 7: Change the Constraints Tab settings to match Figure V3, H3, or S3 (Uncompressed Normal Maps) settings. Click [Process] to complete the optimization.

 

Now after running the "2_Pre-Optimization.bat" batch file earlier, I got 5 folders:

 

vanilla extracted

Vanilla Normal Maps

Vanilla Optimized

Vanilla Textures

Vanilla Uncompressed Normal Maps

 

But, I never got a folder called "Vanilla Uncompressed Textures"

Should I have? Step 6 and 7 seem to be different. Is "Vanilla Uncompressed Textures" a typo for "Vanilla Uncompressed Normal Maps" or did something go wrong?

 

thanks

[sl1dememphis]

Glad you asked the question, I was curious about this, too.