» Sun May 27, 2012 3:08 am Disclaimer: I'm not actually a texture artist myself, though I have some limited experience manipulating textures (re: MMM), so those more knowledgeable than me please feel free to chime in!
The Problem
```````````````
There are so many texture mods of all makes and models that have been released so far, some them fantastic and very professionally made. However I noticed, delving into the files, that some of them have textures saved in the wrong format, while others often forget mipmaps. And given Skyrim is already more demanding memory wise than its predecessors, it's more important than ever to keep an eye on memory usage when using texture mods. Unfrotunately texture mods, especially large ones, if saved using the wrong format can waste a lot of valuable video memory real estate.
When video memory reaches its limit, textures are streamed from main memory causing a huge performance loss. There may be users playing now with texture mods that don't realise the sudden FPS jumps and stuttering they're experiencing are due to taxed video memory on their cards.
But it's not just performance that takes a hit. Visual fiedilty can be sacrificed in order to stay within the limits of video memory. Users are told to run at a lower resolution, or turn down their AA, to recover performance -- but if the problem is a poorly packaged texture mod pushing you past your card's limit, then there may not be a need to do this at all. And if you're an author, keep in mind that if your mod is too demanding people may elect not to use it -- and if you made it to be shared and used, you're losing out from having your work bringing joy to the denizens of Skyrim (read: everyone!)
The Example
```````````````
How important is the correct format? By way of example I'm running a good 30 odd texture mods -- some are large replacers (landscape, NPCs, clothing, armor, weapons for example) while others focus on particular areas (objects, architecture etc). I've selectively chosen them to keep within my video card's memory limit -- 1536MB (Nvidia GTX 580).
Now there are a lot of amazing texture mods on Nexus, but a fair few I've seen so far don't always use the correct texture formats. A high-profile and popular mod (and I don't mean to single you out Chris!) that's done this is Chris2102's Whitrerun HQ Texture Pack.
By default this weighs in at 226M zipped, 487M uncompressed. However for whatever reason, while Chris has saved his textures containing an alpha layer and normalmaps correctly as DXT5, there's a large number of textures without alpha also saved as DXT5 when they can be saved as DXT1 for a significant memory saving. Re-compressing Chris's mod using DTX1 where needed gives us:
- Default -- 487M
- Recompressed -- 362M
And that's just with one mod.
Two other examples I've come across inlcude HQ Towns and Villages where recompressing DXT5 textures without alpha to DXT1 netted a 17M reduction in size (which, given all these textures are used at once, is a saving of 17M in-game) and the Blunt Weapon Enhancement Pack which goes from 90M to a tiny 12M, saving 78M -- here, you might not have all the blunt weapons loaded at once but each one gets a saving of around 3M, so if four different blunt weapons are loaded in a cell that's 12M saved. And, of course, the savings from each of mod add up.
Now before you get too excited, some of the major overhauls -- including the gigantic Skyrim HD and Vurt's Skyrim Flora are both compressed correctly, and there's no savings to be made. But I have, at least in my list, about 18 texture mods -- of just those that I've chosen to download -- that I found I could recompress to gain valuable video memory back.
As an aside, these are all factors that affect video memory usage in addition to textures being loaded:
- Resolution
- Anti-aliasing
- Transparency anti-aliasing
- Triple buffering
- SSAO
- Skyrim: uGrids and extended range tweaks
- Post-processing mods like ENB
The Solution
```````````````
So if you're a texture modder, what are the guidelines to follow?
- Remember to generate mipmaps (these help reduce GPU load)
- Save textures as DXT1
- Save textures with alphas as DXT3 or DXT5
- Save normalmaps as DXT5
- If you've uploaded a texture mod already, and you're not sure about the formats you've used, please check it and re-upload the mod if necessary.
Again my forays into texture creation are limited, so any input from the experts is welcome here -- for example what about bump maps? Specular? Can normal maps be compressed as DXT1 if they have no alpha? Please share your expertise!
Incidentally, I've been using AMD's The Compressonator to examine textures, generate mipmaps, compare textures and of course recompress them. It's a brilliantly easy tool to use, and its image comparison feature esepcially is fantastic (you can see at a glance what impact different compression levels will have). While I can't confirm this, from what I've read it apparently also produces better quality compressed textures than Nvidia's DDS tools, but I'll leave that for the experts to debate.
The Solution Ver 2 (kinda)
``````````````````````````````
Ethatron has released his DDSOpt tool which does a great job at picking up and fixing (by re-compressing a texture or a normal map correctly) some of the issues discussed above. It also has an excellent mipmap generator that adds higher levels of details in the mipmaps, leading to even better texture quality at mid to long ranges.
So -- for users users and especially texture authors -- you can run DDSOpt to optimise textures to be correctly saved in the right format, and thereby reduce VRAM usage. It is still in development however, so if encounter any odd results please post in the http://www.gamesas.com/topic/1330264-ddsopt-of-use/.
-----> However, there is a large caveat <-----
DDSopt can correctly re-compress textures and can sometimes pick up minor issues such as unnecessary alpha channels, but it is not a silver bullet to magically make all your textures perfect. It cannot fix errors in textures and alpha channels created (however inadventently) by the texture author. Things like left-over borders, stray pixels in alpha channels and a whole bunch of stuff that actual texture artists could probably mention that I can't.
In other words, if you make and upload texture mods DDSOpt can help you ensure your textures are properly saved with the most optimal DXT compression format, but it cannot fix problems with textures, alpha channels and normal map generation. This is up to you to get right first time before you upload the mod -- and unfortunately, while testing DDSOpt with Ethatron, there are a lot of mods that have these sorts of issues and as a result DDSOpt can't optimise them. So if you're a texture author, please check your work
DDSOpt can be http://www.skyrimnexus.com/downloads/file.php?id=5755.
Thankyou for reading.
isoku chimes in:
Normal maps are treated the same as everything else. Depending on the alpha, save as DXT3 or DXT5. No alpha = save as DXT1. DXT1 - 1 bit alpha is also a choice if you have an alpha channel with only black and white (aka no grays).
There is also another problem I've seen where textures that shouldn't have an alpha channel have an empty white one saved with it further bloating file size. Solution: delete the alpha channel and save as DXT1.
There is also another problem I've seen where textures that shouldn't have an alpha channel have an empty white one saved with it further bloating file size. Solution: delete the alpha channel and save as DXT1.
MadCat221 adds:
Another thing to add.... Uncompressed textures.
It's been determined in the Oblivion period that DXT compression does Bad Things? to normal maps. Channels aren't compressed evenly, DXT compression artifacting causes oddities when the normal map is rendered.
To get a similar filesize savings, instead, reduce the dimensions to 1/4 its size (or half squared basically, 1024x1024 to 512x512) and save as ARGB8 Unsigned. It's uncompressed, and thus has no DXT artifacting, and the size reduction far more evenly distributes the reduction artifacting for a better looking normal map.
...
Throttlekitty released some nVidia Texture Tools DDS Photoshop Plugin profiles with improved mipmap settings back in '07 for Oblivion modding. They're still applicable for both FO3/FONV and Skyrim textures. Check it out here: http://www.tesnexus.com/downloads/file.php?id=11817
And as a final note.... Do not upsize the texture unless you're actually adding detail to it. Larger dimensions by themselves != more detailed textures. It cannot undo size reduction detail loss.
It's been determined in the Oblivion period that DXT compression does Bad Things? to normal maps. Channels aren't compressed evenly, DXT compression artifacting causes oddities when the normal map is rendered.
To get a similar filesize savings, instead, reduce the dimensions to 1/4 its size (or half squared basically, 1024x1024 to 512x512) and save as ARGB8 Unsigned. It's uncompressed, and thus has no DXT artifacting, and the size reduction far more evenly distributes the reduction artifacting for a better looking normal map.
...
Throttlekitty released some nVidia Texture Tools DDS Photoshop Plugin profiles with improved mipmap settings back in '07 for Oblivion modding. They're still applicable for both FO3/FONV and Skyrim textures. Check it out here: http://www.tesnexus.com/downloads/file.php?id=11817
And as a final note.... Do not upsize the texture unless you're actually adding detail to it. Larger dimensions by themselves != more detailed textures. It cannot undo size reduction detail loss.
teanandcigarettes says:
Mip maps are necessary for almost every texture. Removing mipmaps from normal maps would have a horrible effect on the clarity of the image. Not using mipmaps would result in a "shimmering" effect as seen on the image here: [img]http://www.shinvision.com/wp-content/uploads/2009/06/mipmapping-egz.png[/img]
If mipmaps are removed, the pixels on the left example would be constantly moving. This would be very noticeable on normal maps; from what I've seen normal maps included in most texture packs are done rather badly and are incredibly noisy.
...
Unfortunately, creating texture replacers for objects that had their normal maps baked from highpoly models is pretty much pointless. Their diffuse textures can be tweaked, but modyfing their normal maps in Photoshop will often produce technically incorrect results. Objects like that rely on normal maps NOT to add surface detail, but to define the shading of a lowpoly object and bring it closer to its highpoly version. Upscaling normal maps and overlaying noisy detail on top of it can make it appear slightly sharper, but in most cases it will produce worse results than rendering the normal map at a higher resolution. Here's a massive article about normal mapping in current generation video games: http://wiki.polycount.com/NormalMap The article also has links to tutorials that deal with the subject in more detail.
If mipmaps are removed, the pixels on the left example would be constantly moving. This would be very noticeable on normal maps; from what I've seen normal maps included in most texture packs are done rather badly and are incredibly noisy.
...
Unfortunately, creating texture replacers for objects that had their normal maps baked from highpoly models is pretty much pointless. Their diffuse textures can be tweaked, but modyfing their normal maps in Photoshop will often produce technically incorrect results. Objects like that rely on normal maps NOT to add surface detail, but to define the shading of a lowpoly object and bring it closer to its highpoly version. Upscaling normal maps and overlaying noisy detail on top of it can make it appear slightly sharper, but in most cases it will produce worse results than rendering the normal map at a higher resolution. Here's a massive article about normal mapping in current generation video games: http://wiki.polycount.com/NormalMap The article also has links to tutorials that deal with the subject in more detail.
Ethatron adds:
Oblivion did switch shaders based on the DXT-format and for Oblivion DXT1 means "no alpha", not "1-bit alpha", and it uses the shader which doesn't use the alpha-information. The exception is the UI, there you indeed can use "1-bit alpha", but not for assets used in the game itself. Also, the meaning of "no alpha" changes is you have a color-map or if you have a normal-map. For color-maps the alpha-channel may contain transparency, so neutral alpha is white. For normal-maps the alpha-channel can contain specularity, so neutral alpha is black. For color-maps the alpha-channel may also contain a heightfield, so neutral alpha is whichever solid grey (it's a difference-map, no differences, no effect, only waste of GPU-cycles).
Huleed gives the straight dope:
Normal maps should be saved at quarter resolution (eg, 1024x1024 -> 512x512) as 8.8.8.8 uncompressed. This results in the same file size, and avoids the DXT artifacts which can mess with normal maps.
The thing to keep in mind is that normal maps, essentially, aren't color. They're actually 3-dimensional vectors that are stored using color values, that special shaders read and convert back to 3D vectors to do directional lighting calculations with. For instance, say you have the vector:
{ -0.707, 0.0, +0.707 }
which points a bit towards the side. This gets converted to color as:
{ R: 90, G: 128, B: 218 }
Now, remember that DXT compression is lossy, which means the color that's read will be slightly different than what it originally was. So, for example, you may end up getting back something like:
{ R: 88, G: 125, B: 225 }
which is close, and other neighboring texels (texture pixels) may also be modified to hide the discrepancy. But, this is to hide the difference of perceived color, and again, this is actually a 3D vector. So when you convert it back to a 3D vector, you get:
{ -0.69, -0.98, 0.765 }
Rather different from where it started, no? It's pointing off-kilter, which would cause the texel to be lit incorrectly. Add little bits of "noise" like this all across the face of the surface, and it's not hard to see this is suboptimal when dealing with non-color information.
If it's instead saved uncompressed, the color that's read back will be the same as it was originally stored with, which when converted back, is:
{ -0.706, 0.003, 0.710 }
Much closer to the original. The resolution of the normal map may be quartered, but it will provide a relatively smooth transition between neighboring texels that each better represent their original values, thus has fewer anomalies.
PS. There may be some inaccuracies in the above post, but the idea is there. In essence: DXT compression doesn't play well with normal maps. Using uncompressed formats is better, even if it means quartering the resolution.
The thing to keep in mind is that normal maps, essentially, aren't color. They're actually 3-dimensional vectors that are stored using color values, that special shaders read and convert back to 3D vectors to do directional lighting calculations with. For instance, say you have the vector:
{ -0.707, 0.0, +0.707 }
which points a bit towards the side. This gets converted to color as:
{ R: 90, G: 128, B: 218 }
Now, remember that DXT compression is lossy, which means the color that's read will be slightly different than what it originally was. So, for example, you may end up getting back something like:
{ R: 88, G: 125, B: 225 }
which is close, and other neighboring texels (texture pixels) may also be modified to hide the discrepancy. But, this is to hide the difference of perceived color, and again, this is actually a 3D vector. So when you convert it back to a 3D vector, you get:
{ -0.69, -0.98, 0.765 }
Rather different from where it started, no? It's pointing off-kilter, which would cause the texel to be lit incorrectly. Add little bits of "noise" like this all across the face of the surface, and it's not hard to see this is suboptimal when dealing with non-color information.
If it's instead saved uncompressed, the color that's read back will be the same as it was originally stored with, which when converted back, is:
{ -0.706, 0.003, 0.710 }
Much closer to the original. The resolution of the normal map may be quartered, but it will provide a relatively smooth transition between neighboring texels that each better represent their original values, thus has fewer anomalies.
PS. There may be some inaccuracies in the above post, but the idea is there. In essence: DXT compression doesn't play well with normal maps. Using uncompressed formats is better, even if it means quartering the resolution.
Resources
````````````
The Compressonator -- http://developer.amd.com/tools/compressonator/pages/default.aspx
Oblivion DDS guide -- http://cs.elderscrolls.com/index.php/DDS_Files
Wikipedia on DXT modes -- http://en.wikipedia.org/wiki/S3TC
Generating normal maps (thanks to teaandcigarettes) -- http://wiki.polycount.com/NormalMap
More on DXT formats (thanks to teaandcigarettes) -- http://wiki.polycount.com/DXT
Another good read on DXT formats (thanks to Phitt) -- http://www.fsdeveloper.com/wiki/index.php?title=DXT_compression_explained
How to choose the right DXT compression (thanks to Thottlekitty) -- http://cs.elderscrolls.com/index.php/Choose_the_right_DXTC_compression_algorithm
Normal map workflow (thanks to Thottlekitty) -- http://www.poopinmymouth.com/tutorial/normal_workflow.htm
Combining normalmaps (thanks to Thottlekitty) -- http://www.rodgreen.com/?p=4
Throttlekitty's Keep Details profiles for Photoshop -- http://www.tesnexus.com/downloads/file.php?id=11817
DDSopt by Exatron -- http://www.gamesas.com/topic/1330264-ddsopt-of-use/
)
