tony971

The unofficial patches part of the guide looks like it's still based on an old version of Optimized Vanilla Textures.

It's really not a major disagreement. I don't think that USLEEP and UHRP conflict enough to bother using UHRP. Neovalen would rather just download it anyway. Either is correct.

So the obvious question is "why doesn't MO use the same INI loaded BSA for executables that it uses for Skyrim?" And would having unnecessary BSAs loaded break any more functionality than loose files?

Well now that the question is raised, it's not just limited to the vanilla textures. It applies to every mod that uses a dummy plugin.

Even the TES5Edit team doesn't know. https://github.com/TES5Edit/TES5Edit/issues/334

Well the good news is I don't know of any other mods that depend on MO's BSA loading function. But it would be nice to see xEdit updated to accommodate. I think it was Sharlikran who helped me out last time I did something funky that needed a new xEdit function. I don't remember, exactly, though. Edit: I've opened up a ticket with TES5Edit to request this functionality https://github.com/TES5Edit/TES5Edit/issues/334

AHHH THIS TOTALLY MAKES SENSE. Okay so the problem is that DynDOLOD doesn't know to load BSA files loaded by MO. But even if none of my files are used, the LODs should be the same as the ones for vanilla Skyrim.

I still think it's really advantageous for MO to not load the original textures. I might tell my users to rename the file but deactivate the mod while running DynDOLOD.

It's only going to check Skyrim - Textures.bsa regardless. So yes, it would be better if DynDOLOD loaded all of my textures, but it looks like that won't happen no matter what. And since my textures are visually equal to the vanilla ones, the LODs should be identical.

I'm guessing it statically loads Skyrim - Textures.bsa. Since MO would now be loading mine instead of the original, it's not even checking Skyrim - HD02.bsa. Easiest solution is to not rename the file or to wait until after running DynDOLOD to do so.

Well now I'm just confused. I've never used DynDOLOD so if my initial guess was wrong, I have no idea what's going on.

No need to extract anything. Just don't rename it until after you finish using DynDOLOD.

Sounds like something that needs updated with DynDOLOD. Skyrim - HD01 and Skyrim - HD02 each have about half of the game's textures. If DynDOLOD isn't loading both of these archives when one of them is named Skyrim - Textures, then half of the game's textures would be missing. I just don't know why it wouldn't load both. Something to ask the author. Oh wait I know why. It's only looking at Skyrim - Textures.bsa. Since MO doesn't load the real Skyrim - Textures.bsa when one of the Skyrim - HD bsa files are named the same, it's only loading half the textures. DynDOLOD would have to be specifically updated to work with my mod if users rename their file.

The difference between using the UHRP and not (if you're using Optimized Vanilla Textures - HD) would be if USLEEP and UHRP try to correct any of the same textures. Because you still need USLEEP if using my mod, and USLEEP should be placed after it in your load order. So there may be 1-2 textures that the UHRP overrules from USLEEP if you have it. I don't know if they actually conflict. I don't have UHRP installed, myself.

Flawless.

Now that version 6.0 is all wrapped up, I figure you guys should know what it is before users start asking the difference between mine and z's. The textures themselves are the end result of following your DDSopt guide for Skyrim. Except that I only collapsed textures to 4x4 instead of 1x1. The major feature of the mod is that it'll sandwich itself between the vanilla assets and unofficial patches. It'll never overwrite anything it's not supposed to. (Without using plugins) Edit: The HD versions are a merge of the official High Res DLC and original textures. The unofficial high res patch fixes were incorportated as well. So it'll also act as a substitute for those.

Mine actually covers all of the textures that don't make the CK freak out (currently). The next version doesn't have to worry about the CK or it's weirdness. But I do trust your optimization skills over mine. My mod's claim to fame is the plugin-less installation method for NMM users. I'd gladly rebase on your recommendations.

Hey guys. I'm coming back to the optimization scene (finally found my laptop charger). Anyway, I've figured out how to get the plugin-less version of Optimized Vanilla Textures to also be conflict-less. If you have new texture optimization standards, I'll include them when I release the new installation method. NMM users will finally have optimized textures that load before the unofficial patches without needing a plugin or compatibility worries Of course, the only difference I might have is making the collapsed planar textures 16x16 instead of 1x1. It seems to calm some nerves.

Creation Kit specific issues can be ignored. The (soon-to-be) updated installation method makes the CK a non-issue.Edit: One visual regression that has been noticed, however, is in pine trees. They become less full after optimization.

I've just had a breakthrough on the installation method front. The next version will get overridden by everything and be compatible with every tool. And that's without using a single plugin

I don't believe that there would be any visual regressions. Even if it's stretched weirdly, it's monochromatic. There's not a lot to distort. The only issue would be hardware (and the Creation Kit). CK users have reported many times that if the facetints are touched, the CK freaks out and they end up with gray face. The difference between 1x1 and 16x16 is negligible, though. If using 16x16 textures potentially avoids hardware issues, I don't really see a downside to using them.

No, I went through every texture in the output directory and arranged by file size. It took forever. I think the best way to test performance would be to make a test zone in which a lot of the collapsed textures are present. Test it once with the 1x1 textures made by DDSopt and then again with the 16x16 textures I provided earlier.

Oh I went through every single dds in the game after running DDSopt and checked for 1x1 textures. Doesn't matter if they were a mip or native texture. If DDSopt collapsed them, I replaced them.

Optimizer Textures auto-collapses patterned textures to 16x16 (or smaller if you want) and then you can user-define to cut the other textures' sizes in half until you get them to your desired size.

16x16(4) just seemed like a good number, as objects won't be smaller than that. The difference won't appear in-game. It's all performance-related. alt3rn1ty has a lot to say on the subject if his attention is drawn to this thread. Here are all of the un-collapsed textures if you want them.