SKYRIMLE Optimized Vanilla Textures (by tony971)

[Kelmych]

I haven't seen any evidence that collapsing the portion of the Skyrim terrain textures that DDSopt collapses causes problems. If STEP wants to take an official position that collapsing should generally not be done, there should be some technical results that indicate there is a general problem. There are certainly a few examples of texture collapse that causes problems, especially for textures used for interface screens. Other than interface textures, "DDSopt.ini" contains one Skyrim texture and 3 Fallout New Vegas textures that are not properly handled when collapsed. Note that testing of these has been done on 1 or 2 cards vs. a large set of cards, and they were added to "DDSopt.ini" because there is evidence that they can cause problems on at least some graphics cards. I'm the source of the one Skyrim example; however, this is the only example I have observed in Skyrim using my graphics card.

 

 

Here is the quote from Ethatron (it's included in the DDSopt guide); he indicates there could be a problem but note that he never says that collapsing should not be done:

"

• planar (1x1) textures - The number of textures which have only one distinct color value (monochromatic). These textures may be converted to 1x1 size without loss, which reduces size and should increase performance, although not all hardware likes 1x1 (reasons unknown at this time).
• "

[tony971]

As for the mod's implementation, LOOT and BOSS now sort the plugins correctly.

Wrye Bash and TES5Edit are working on the ability to read custom ini files. See here. Until they work it out, plugin-less users will have to edit their Skyrim.ini's sResourceArchiveList2 line to match their [DLC].ini line after installation.

VirusTotal has a few false positives for the Textures Install.exe and Textures Uninstall.exe. I've submitted false flag reports to applicable antivirus companies. Three have already responded with new definitions.

After these remaining issues are resolved, the mod will be ready for STEP review.

Edited September 1, 2014 by tony971

[Aiyen]

Just because I was just curious... 

a 16x16 mono chromatic .dds file with no mipmaps (why would it need it), saved at DXT1 compression is 256 bytes. 

a 64x64 become 2.12 Kb 

 

For the few textures that are just mono chromatic could just manually be made to be 16x16 or even lower...heck even going to 128x128 would probably be "good enough". In all cases then it is just weird that the developers thought it was a good idea to even have a shader that requires a texture lookup for a color! It could just have been coded in as a setting. Then there would have been no need for a texture lookup.. which is much more expensive then a defining a float value. Oh well, guess they made some code for a gradient and then just copy pasted and called it a day or something similar hehe. 

 

Regardless then there are plenty of options to avoid using a non power of two size and then avoid all potential weird errors. In my book the technical argument would be "you have a .dds texture... it needs to be a power of 2". 

[tony971]

Alright, version 3.1 is live. All known issues are fixed.The only pending item on the itinerary is getting NANO-Antivirus to stop having a false positive for the installer files. I've made a sticky post on the mod's forum asking users to submit the installer file as a false positive until NANO-Antivirus updates its definitions. Other than that, the mod is ready for STEP consideration.

[viper37]

Amazing work.  Not that I understand all the technical stuff I've read on the last 4 pages , but I realize it's a lot of work and makes my game better&faster.Thanks to tony and all who contributed.

[alt3rn1ty]

Tony - The only thing I dont get about the finished thing ( as Aiyen also mentioned earlier ) is why the need for all the installation complexity ?

 

The ini's ?

The installer.exe ?

The need to replace the vanilla Skyrim - Textures.bsa ?

 

You could have one method which suits all Mod Managers - Fake.esm all of them ( currently that just means your Skyrim - Textures.BSA needs renamed to something like OptimizedVanillaTextures.bsa, and make a fake.esm to go with it ... All the rest are done )

 

The only thing you need to care for really is that USKP texture fixes ( which you do not include ) end up winning :

 

Skyrim.esm

Update.esm

OptimizedVanillaTextures.esp

Unofficial Skyrim Patch.esp

Dawnguard.esm

Dawnguard - Textures.esp

Unofficial Dawnguard patch.esp

Hearthfires.esm

Hearthfires - Textures.esp

Unofficial Hearthfires Patch.esp

Dragonborn.esm

Dragonborn - Textures.esp

Unofficial Dragonborn Patch.esp

 

The installer for this could be as simple as this one - No exe or ini's required, and Wrye Bash / MO / or NMM can all install it without problems or virus checking concerns ( .vbs scripts and compiled vbs have been famously regarded as suspicious for a long time ).

You could also add a Wrye Bash wizard.txt if you wanted the options auto-selected ( but for something as simple as this just manual sub-package selection is good enough )

 

What you have at the moment seems a bit OTT for what it is. By getting rid of the original Skyrim - Textures.bsa you are not making the game loading any more optimal ( Not in my experience anyway with VRT on my laptop, performance has always been far better than vanilla without the need to replace the original bsa ) ..

 

.. Is the need for your methods of installation just a MO thing ?.

 

Please dont take offense, I just dont understand the need to do it the way you have, and I am very familiar with all the options as per the BSA and you and Load order and you topics.

 

 

And if getting this malware recognition to go away is too problematic - Well the solution is easy as above.

 

 

In the long term, I can see the typical nexus crowd repeating the same questions page after page ad infinitum. Not your fault of course that the average nexus user does not have enough attention span to read a description longer than two sentences, but I reckon you will be plagued by them.

 

Top tip, if after a while you are satisfied you have covered every question possible, and no longer need any feedback - Turn off the comments :), then the only source of info becomes the description and they are forced to read instead of lazily just posting a question which has already been answered.

Edited September 6, 2014 by alt3rn1ty

[tony971]

The reason for the complex installer (complex on my end, simple on theirs) is because every texture mod that I see has one of two complaints:

1. "Why do I have to use this dummy plugin? I already have over 9000 plugins!!!"
2. "If these are loose files, won't they overwrite everything?"

So I set out to fix that. Using all of my installation methods, textures will either directly replace their originals or get loaded between their originals and their unofficial patches. Always. Being able to do it without wasting a plugin slot was a fantastic bonus.

As far as my reasoning to directly replace the Skyrim - Textures.bsa and/or HighResTexturePack0X.bsa files, compressed vanilla archives actually save more VRAM than their original .bsa files. Kelmych has done testing on this. It also saves me from having to do the ini trick with four more archives (which would force me to make Nitpick a requirement).

Edited September 6, 2014 by tony971

[tony971]

I wonder if it would be worth it to tell users to re-pack their vanilla resources with BSAopt and then include a batch file that makes these changes: https://forum.step-project.com/topic/5111-bsa-archive-flags/

[alt3rn1ty]

 

I wonder if it would be worth it to tell users to re-pack their vanilla resources with BSAopt and then include a batch file that makes these changes: https://forum.step-project.com/topic/5111-bsa-archive-flags/

:) Your call on that one I would say - Possibly link a mod Article for advanced users tips ?  

Just because I was just curious... a 16x16 mono chromatic .dds file with no mipmaps (why would it need it), saved at DXT1 compression is 256 bytes. a 64x64 become 2.12 Kb  For the few textures that are just mono chromatic could just manually be made to be 16x16 or even lower...heck even going to 128x128 would probably be "good enough". In all cases then it is just weird that the developers thought it was a good idea to even have a shader that requires a texture lookup for a color! It could just have been coded in as a setting. Then there would have been no need for a texture lookup.. which is much more expensive then a defining a float value. Oh well, guess they made some code for a gradient and then just copy pasted and called it a day or something similar hehe.  Regardless then there are plenty of options to avoid using a non power of two size and then avoid all potential weird errors. In my book the technical argument would be "you have a .dds texture... it needs to be a power of 2".

Looks like for some of the planar textures there is reason to keep them at the original 256 : https://forums.nexusmods.com/index.php?/topic/2037084-optimized-vanilla-textures/page-27&do=findComment&comment=18189004  

First of all, I am using version 1.0. When I export facegen data (ctrl F4) in Creation Kit, my NPCs have grey face bug and I get error popups (example 1) saying:FACEGEN:TINT MASK TEXTURETexturesActorsCharacterCharacterAssetsTintMasksskintone.dds is not the correct expected dimensions of 256 x 256. Please resize the texture to match these dimensions.There were a few others like female cheek.dds. Were these files optimized? I did export facegen data on the same NPCs before installing this mod with no grey faces or errors. Hope I gave enough info. Going to uninstall and see if everything works again. Can any other things cause this?

^^ @ Kelmych - Something to note for DDSOpt guide, or ini / filtering ?Edit : Although, if the mod was not replacing the original Skyrim - Textures.bsa .. Maybe this would not be a problem for anyone using the creation kit which would not source the textures from a mods bsa full of replacer textures ?. Not sure, I have only rarely used the Creation kit.I have never had this problem reported to Vanilla Reduced Textures which has a custom bsa, but then again I dont include all of these types of textures, some of the tintmask textures I have are carried into my mod from Unofficial patches, and I believe they should be at the games original texture sizes.Need to check my files out when I get home in a few days. Edited September 7, 2014 by alt3rn1ty

[Kelmych]

Comments about potential problems when optimizing body-related textures were added quite a while ago to the DDSopt guide (e.g., see the sidebar "Note about Uncompressed Texture Files, Body textures and the Batch file" in this section of the guide). While collapsing textures doesn't seem to have much effect most of the time, it can certainly cause problems sometimes with body textures. The other problem I found was converting uncompressed body textures to compressed during optimization, which can also at times cause many problems. The batch files for mods separate body-related textures into a separate folder because they are more sensitive to optimization parameters than other textures. The tint-tone maps are sensitive to optimization parameters, and the textures used for major body parts like the body and head are often uncompressed and can sometimes be quite large leading to different optimization issues.

 

For the vanilla textures the batch files pull out some of the body-related textures and prevent them from being optimized (or in some cases changed at all) or put them in folders where they will not be reduced in size or have their format changed from uncompressed to compressed. This is done separately for the tint-tone maps and the major body textures (especially the model space normal maps). The intention is that the vanilla optimization using the DDSopt guide procedures should not cause problems with body textures.

 

There has been a lot of discussion about the appropriate optimization parameters in another thread about the one large model space normal map for female bodies in the vanilla textures. There is no single answer that's always correct; the MSN in the vanilla textures can be reduced to R5G6B5 at full or half resolution, but gets corrupted if the format is unchanged and it is reduced to half size. For the same MSN file with other body mods the best optimization parameters to reduce size while losing little quality are often different.

 

DDSopt dosen't know which mod the texture file came from, so there can only be useful DDSopt.ini entries when the behavior problem is true for both vanilla and mods that replace the vanilla textures. Most of the value in the DDSopt.ini file is to handle models where the alpha channel is used for unusual purposes.

 

If there are any known problems with body-related textures using the DDSopt guide procedure, let us know and we'll change the procedure or parameters. Since, unfortunately, some of the problems are specific to the particular graphic card or driver software being used there isn't any way for the testing we do to cover all possibilities.

[tony971]

The forum post that alt3rn1ty linked could be considered an issue report.

[Kelmych]

We'll add a note in the DDSopt guide that while graphic cards are supposed to be able to work with collapsed textures, tools like the CK (and probably other graphics creation tools) don't usually handle textures that are collapsed. Some other comments on working with optimized textures and graphics software will also be added.

[tony971]

The vbs install script has been made to elevate UAC privileges. This has gotten rid of the need to have an executable file, thus making VirusTotal have a clean scan.The last thing that I want to do is make all planar textures 4x4 for multiple of 2 purposes. Also, any planar textures that the CK freaks out about not being their original size should be made their original size.Edit: Turns out that the CK is just throwing another one of its meaningless warnings. It can be ignored. But I still want to make planar textures a power of 2.

Edited September 17, 2014 by tony971

[tony971]

4.0 has been released. This fixes everything that is in my ability to fix. All collapsed textures are now sized in powers of 2. All Creation Kit errors are fixed. The mod is now ready for STEP consideration.Advantages over the DDSopt guide:1. The textures are already pre-packaged with installers for NMM and Wrye Bash users.2. They will always overwrite their vanilla counterparts and nothing else (whether the user chooses to use plugins or not).3. All collapsed textures are sized in powers of 2.4. Can directly replace Skyrim - Textures.bsa and/or HighResTexturePack0X.bsa without causing errors in the CK.Things to be cautious of:1. Not all tools know the trick used to get the load order correct for plugin-less users (TES5Edit, Wrye Bash, and the Creation Kit all do).If a tool does not know to read the Skyrim.ini file when loading BSA files, it will not load the DLC BSA files. You'll be able to tell which tools don't know to read the Skyrim.ini because they'll have an error about missing string localization files. Users of any tools like this must use the plugin option.2. If a plugin-less user replaces their Skyrim.ini file after installing, no (known) tools know to read the backup ini files. The game will still run, but tools like TES5Edit and Wrye Bash will not load the DLC BSA files. Both tools are working on this functionality. In the mean time, users will just have to re-run the installer file after replacing their Skyrim.ini.

Edited September 19, 2014 by tony971

[darkside]

Can I unpack the BSA and simply use it as loose files in MO? No plugin needed.