Guide:DDSopt/FAQ

DDSopt Technical FAQ

NOTE

TheDDSopt and Texture Overhaul Forum hosts occasional DDSopt 0.8.0 technical Q&A sessions with Ethatron, the creator of DDSopt. This FAQ includes the material from these sessions. It is intended for intermediate and advanced users.

Question 1

Many compressed rectangular textures (e.g., 2048×1024) have bottom mipmaps of 1x1 where we expect to see a minimum of 2x1. When such textures are processed by DDSopt, sure enough, the lowest 1x1 mip is dropped. DDSopt now also has a setting to prevent this behavior.
Q1: Do these lower 1x1 mips play any role on what we see in game, and if not, why is there a DDSopt setting to retain them?

A1: Lower mip-levels are selected by the filtering-hardware in the graphics-card when surface angles are very steep or when the total scale of the texture becomes smaller. When this happens for a 1x1 pixel texture, it means that the entire texture is displayed at a resolution of only one pixel. If trilinear filtering is enabled, this happens even at 2x1, and with anisotropic filtering, this basically only happens when the entire texture-size falls below 1x1 pixel. It is not obviously clear if Skyrim displays any objects below 1x1 pixel, but probability is rather low. If does occur, then the graphics-card hammers only on a single texel, but compressed textures have a minimum block-size of 4x4 ... damn. Regardless that only one texel is requested, 16 are effectively decompressed (not really, but the memory of the block is read completely, since no memory-system reads single bits from the chips but rather entire 64-bit units. Performance-wise, there is very little difference in trilinear-filtering 1 versus 4 texels, as the bottleneck is the memory-latency, and the block is already in on-chip cache --there is probably even pay a penalty for having 3 full blocks for the lowest mips (1x1 expanded to 4x4, 2x2 expended to 4x4 and then 4x4) as memory is cycled thrice (800 clocks + 800 clocks + 800 clocks), which is an inefficient use of the cache. Thus, all mips below 4x4 block size are eliminated for efficiency.

It sounds like you are suggesting that these very small mip-levels (below 4x4) do not supply any significant quality information to the rendered image in-game and that eliminating these lower levels will provide some measure of performance gain with no perceptible cost in quality. If so ...
Q1.1: Why does DDSopt only strip 1x1 only and not the three lower mip-levels from the compressed output?

A1.1: DDSopt only omits smaller mips for uneven dimensions (drop 1x1 and 1x2 for a 1x4 texture), which is sort of a middle-ground. It's also not a perfect heuristic, a 1x256 texture would not receive any mips at all; however, the effects of one or the other or the 4x4 rule are so tiny that it's really more something for an academic discussion without any gameplay significance. It certainly certainly can't be measured with a standard utility. (Thus this functionality is simply punctilious or a representation of meticulousness).

Question 2

Q2: In the DDSopt output, there are several lines that make up the Final Report. Ex:

Final report "D:/Skyrim Mods/Mod_Working/DDSopt/out":
processed files: 48
modified textures: 27
skipped textures: 0
fixed textures: 0
fixed files: 0
broken files: 0 (0 without fixed ones)
planar (1x1) textures: 0
changed texture formats: 16
i/o delta: -36413610 bytes
tex delta: -21670756 bytes

The information contained in certain of these is pretty obvious; however, a couple of variables are somewhat unclear as to what can be gleaned (highlighted).
Q2: Could you briefly describe The DDSopt log results and provide an example or two of values that might raise and eyebrow versus those might be expected?

A2: That's tough. Let's try:

fixed textures - The number of corrupt textures that have been fixed. These are currently textures which are too "short" or truncated textures (few bytes missing at the end). These are relatively infrequent and probably an artifact of the software used in the texture creation process.
fixed files - A remnant of NIFopt that will always be 0. Refers to repaired models mostly (i.e., can be ignored).
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).
i/o delta - This is the global incoming/outgoing delta. For example, when a BSA is processed, DDSopt uses the size of a file inside the BSA (the compressed size if applicable) and writes it into another BSA. The sum of those differences is the i/o delta value. If a DDS is not touched, it is still possible to get i/o deltas != 0 because the compression in BSAopt/DDSopt is about 10% better than Bethesda's. If you decompress a compressed BSA to directories, this delta is likely positive (out is bigger than in).
tex delta - This is only the recorded change in size from changes to texture-formats, resolution and mip-maps, so it does not consider compression effects due to i/o to/from BSAs. This is the most interesting number with regard to texture treatment.

Question 3

Q3: Some texture mod authors (e.g., Isoku) provide uncompressed tangent space normal maps (e.g., A8R8G8B8, R5G6B5, etc.). Are uncompressed normal maps preferable to the compressed ones that DDSopt creates?

A3: Uncompressed (not DXT) normal maps are preferable. IGiven enough noise (few smooth areas), 565 and 4444 quantized normal-maps work well as a compromize for reduced-information uncompressed format. Ethatron uses 565 uncompressed for model-space normals and HQ water textures without much noticeable quality loss. Tangent-space normal maps vary too much to apply a general rule of thumb. Often the uncompressed size is prohibitive, so format information reduction is doable. In reality, large normals can be reduced to half resolution and the 565 format applied, which matches exactly the size of DXT1. If an alpha-channel is involved, it'd be 4444, and that may go bad, depending on the amount of info lost.

Question 4

Q4: One example of truncated textures is in DSI High. DDSopt reports all of the normal maps as being truncated. Interestingly, this is the only Isoku mod for which DDSopt reports truncated textures. There are a few other mods that DDSopt reports as having truncated textures (in addition to Soul Gems Differ and DSI High). Is this a problem?

A4: In reality DDSopt itself doesn't do anything to these textures. The DirectX driver loads these textures and saves them. In this turnaround the textures are "fixed" inside DirectX. DDSopt logs when the w*h*pixelsize != filesize, because it should. Maybe the textures have some fishy alignment or something like that (DirectX will align data according to the "rules"). If DirectX is not used to write out the texture, the result can be unexpected. GIMP probably doesn't. Not a big deal usually.

Q5

Q.5: Does the INI file only let the user declare compression overrides and exclusions (i.e., by listing full texture path/file), or are the section names meaningful in a programmatic sense (i.e., are textures listed under different sections treated differently by DDSopt)?

A.5: The .ini's purpose is two-fold. Defining the compression on a joint texture-type (3 channels can mean 3 independent channels, or color or a vector, or xy + height etc.). And defining the content of the alpha-channel. As there is no 4 channel joint data-format in use in games that I know (CMYK would be one fe., even though even there it's arguable if K is really in dependency with CMY). So a texture is always "joint"+"extra", "joint" is always present, that's the seed-plane, and "alpha" is optional. You define compression on the seed. This are the supported seeds:

CODE: SELECT ALL

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- mark textures to be tangent-space normal-maps, enables specific compression
taking unit-halfsphere property into account
- [b]compression-format is supported here[/b]

[NormalsTangentSpace]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- mark textures to be model-space normal-maps, enables specific compression
taking unit-sphere property into account
- [b]compression-format is supported here[/b]

[NormalsModelSpace]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- mark textures to be color converted
- [b]compression-format is supported here[/b]

[DiffuseColor]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- mark textures to be greyscale converted
- [b]compression-format is supported here[/b]

[DiffuseGrey]

The supported extras are: CODE: SELECT ALL

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- mark textures to have an alpha-channel with opacity, enables specific
compression taking this into account
- [b]compression-format isn't supported here[/b]

[AlphaOpacity]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- mark textures to have an alpha-channel with foliage, enables specific
compression taking this into account
- [b]compression-format isn't supported here[/b]

[AlphaFoilage]

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- mark textures to have an alpha-channel with something custom, disables
specific compression only working for opacity
- [b]compression-format isn't supported here[/b]

[AlphaCustom]

All of them (seed + extra) have their own processing. Normals are normalized, tangent-space vectors are possibly stored partially derivative, opacity gives importance to color (the more transparent the less important the exact color-value), foliage is possibly made sharper. The settings (in the menu) correspond exactly to each of these types.

Q6

Q.6: When I run DDSOpt there are sometimes no compression changes (e.g., DXT5 to DXT1), no changed texture formats, and no tex delta, but DDSopt says there are modified textures. When this happens, is DDSopt still making changes to the texture data but the changes aren't affecting the size of the texture? One example of such a texture file is the Chests_Rich_Dirty mod in STEP.

A.6: Recalculating mip-maps counts as modification. If nothing else happens the file-size is the same.

Q.6.2: So, if I understand correctly, DDSopt can recompute and replace the mip-maps, which could be done without changing the texture file size since the mip-maps have fixed sizes. The mip-maps would be different than before but still the same size. Ideally they would be better than what was previously in the texture files. That makes sense, I just didn't realize DDSopt does this.

A.6.2: Yes, that's correct. I use an "Infinite" Response Filter (IIR) for calculating the mips. "Infinite" in quotes because of course in computers everything is finite, but I fe. do an exact average of all of the texture for the 1x1 mip, not an average of the upper 2x2 mip, which means the response-length (the width) is all of the available input, which makes it practically identical to a real IIR. The reason is that textures are stored as integers with limited precision, and it is actually theoretically possible to get a black 1x1 mip from a bright texture when each successive mip->to->mip down-filter rounds down and thus gets a fraction darker each time. I also filter normal-maps in R^3 (3D-space), and do exact algebra on them, which means DDSopt's filtered normals are always as if you make a lower-resolution normal-map directly from the mesh.

Processing Foliage Textures

Q: What does DDSopt do with foliage textures

A: It's an alpha-texture super-sampling issue, see here for what Skyrim does NOT, and here for what Skyrim does:(same as they did in Oblivion).

Look how the tree-textures are hand-tuned by the Bethesda artists:

Above is normal filtering, below is original special filtering.

Except hand-managing foliage-textures and leave it to everyone's taste, it's difficult to identify "foliage" automatically and apply a different alpha-channel filtering. I'm open to suggestions how to identify foliage-textures though.

DDSopt Options

Q: I already notice some very nice added features.

Ability to preview each mip level (very nice)
Added functionality to the Ignore menu, including extra file-format qualifiers (very nice)
I see that the preview pane uses italics and now there is a new purple font color (ignored textures?)
Three new Behavior-menu options
Raise alpha opacity at each mip level (this is the automated mock of the custom edits to the lower mips of treepineforestbranchcomp.dds?)
Contrast-correct mipmap filtering for alpha (not sure what this does, but I assume that it is intended to soften edges where opacity is increased maybe by adding gray levels to the alpha?)
Don't eliminate lower mip levels (you added it at my behest, but I would like to know when this might actually be useful... perhaps it is not?)

A:

options: No changes here, only better names and positions for quick comprehension.
purple: Right, purple are files which could be processed (converted or optimized ...) but won't because of some setting (ini, or menu).
italics: Is for indicating compressed files in the input (compressed in the BSA or NTFS compression).
raise alpha opacity: This corresponds to a brightness adjustment to the alpha-channel when they are merged for the lower mipmap-levels from the higher resolutions. It doesn't appect level 0, just lower ones, and successively stronger. It's a balanced value, so it won't go really strong. It's tied to foliage, which can be marked as such in the ini.
contrast-correction: This corresponds to a contrast adjustment to the alpha-channel the same way as above, just that here dark-grey gets blacker and light-grey gets whiter. This helps a lot with the inevitable blurriness of the alpha-mask when you go down the mipmap levels, it works for any texture with opacity in the alpha-channel, and won't be applied to those which have other stuff in the alpha-channel.
don't eliminate: I wouldn't use it, but if someone wants to go purist, there is the option.
difference previews: Lots of them, nice ones, I like the angular ones (color hue and normal rotation) the most and those show the "bad" loss in DXT-compression. Magnitudes (of slope or brightness) are not that "bad" losses, and for partial derivative normal-maps it's a conscious adjustment (>60° slope will artifact the lighting to some degree - in plain words >60° makes normal-mapping look unrealistic fakery instead of quite cool fakery).
save as: Manually saving a texture to it's planned location (the default one) with automatically activate the difference view.
ratio: In the drop-down you can see now the ratio of "current format" vs. "chosen format", so you know if you go smaller, or stay the same, or grow in size.

All the fixes I made for next version of BSAopt are in as well of course.

General FAQ

The DDSopt and Texture Overhaul forum has had many useful discussions about various aspects of texture processing and optimization. This section includes some of the question and answer material from the forum that is likely to have general interest. When appropriate the material is assembled from discussions spanning many posts, and editing of the material used in these answers is done. Currently there is not much material in this section; it would be useful if users identify topics that should be included or (even better) take material from the forums and add it to the FAQs. This section is intended for all users.

List of FAQ Answers:

Q1: What are Mipmaps?

Q2: What Texture Formats can DDSopt Process?

Q3: What functions does the Vanilla Texture Optimization in this Guide provide for Vanilla Textures

Q4: What texture resolution should be used, especially for normal maps

Q5: How does DDSopt compare with Optimizer Textures

Q6: How should mods from Steam Workshop be used

Q7: How does Optimization affect the use of the Creation Kit

Q8: What are Collapsed Textures and How are they Used

Q1: What are Mipmaps?

Mipmaps are smaller copies of a texture that are used for rescaling object details in game as one moves away from them and they get smaller (i.e., rather than dynamically resizing, which would create aliasing artifacts and require more resources). Imagine a brick with two dots painted on the surface. As one moves away from the brick, it gets smaller and so do the dots. Furthermore, the dots appear to move closer together, since the entire brick's outline is reduced. Thus, the brick and its 'texture' details (the two dots) 'scale' with one another as the 'image' is reduced. Imagine that the brick (i.e., the image outline) scaled correctly, but the two dots (i.e., the texture) remained constant. The effect is like cropping in on a high res texture and then placing that cropped image far away... without the context of the entire texture, that little spot you cropped to is meaningless. It just becomes a color without detail. It turns out that some textures are released without all of their corresponding mipmap reductions. So a 1024² texture should have mipmaps of 512², 256², 128², 64², 32², 16², 8², 4², 2², & 1². DDSopt fills in these missing mipmaps whilst it ensures that certain textures get compressed correctly if they are not already.

Q2: What Texture Formats can DDSopt Process?

The Support tab in DDSopt shows all the texture formats that DDSopt can process. DDSopt includes special compression approaches for several different types of textures:

tangent-space normal-maps (files ending in _n.dds),
model-space normal-maps (files ending in _msn.dds),
textures with converted greyscales,
textures having an alpha-channel with opacity,
textures having an alpha-channel with foliage, and
textures that use the alpha channel for custom purposes such as height maps.

It can handle a wide range of texture types and formats, and is able to automatically identify many of these automatically.

Q3: What functions does the Vanilla Texture Optimization in this Guide provide for Vanilla Textures

Note that uncompressed textures have better graphic quality than compressed texture of the same size; this is especially true for normal maps. The batch file and associated instructions keep all uncompressed textures as uncompressed, unlike some other available utilities for optimizing the vanilla textures which convert these to compressed.

The batch files and instructions provide following:

Duplicate file removal:

Removes 721 duplicate files and 34 associated folders from the three HRDLC (by running the HRDLC_Clean_Start.bat file)

Compressed color maps:

sorts color maps textures so they are optimized with the default being no change in texture sizes (users can change these if desired, of course)

Compressed normal maps:

prevents optimization of 12 tangent space normal maps for which DDSopt optimization makes a vanilla texture artifact even worse

sorts exterior and interior tangent space normal maps for optimization. With the recommended parameters the only exterior normal maps textures recommended for size reduction are 5 large (2K) STD and 5 large (2K) Dawnguard normal maps

Uncompressed model space normal maps

prevents any optimization of 22 uncompressed MSN textures in HRDLC3 and 1 in STD. Any size reduction of the one large (2K×2K) MSN yields a corrupted texture, although changing to R5G6B5 format does not cause corruption. (the DDSopt compression options found when DDSopt is initially installed converts these to compressed, reducing graphic quality)

Uncompressed facial tint related textures:

sorts all of the tint/tone textures in the tintmask>, facetint, and facemods directories so they are not optimized. Since most these are monocolor textures, default DDSopt compression options would have collapsed many of these to 1x1 textures. This is generally OK with graphics cards, but the Creation Kit and other related graphics tools need full resolution versions.

Uncompressed terrain tangent space normal maps in HRDLC2:

selectively sorts 5174 uncompressed exterior terrain TSN texture files so they are optimized as uncompressed Some DDSopt compression parameter options converts these to compressed and the textures are then usually collapsed. Some users reported problems with these if they are converted to compressed. The result of this is that DDSopt only collapses less than 10% of these, and makes some format conversions on a portion of the other ones.

Uncompressed terrain color maps in HRDLC2

sorts 5180 uncompressed color maps so they are converted to compressed, saving significant disk space without significant quality loss since DDSopt generally collapses these as most are monocolor.

Other files:

prevents optimization of any textures in textures/interface . These don't benefit from optimization.

Q4: What texture resolution should be used, especially for normal maps

Based on this forum post: The higher the resolution of the normal map, the closer an item can be before it will start looking blurry. Hence for stuff like weapons, etc. that are always up close when you are playing in first person a normal map of 2k is the best, or you will start to see really blurry textures. The same for armor since you are fighting enemies in close combat most of the time (unless you are a mage or archer only), hence it would also be a good idea to have better quality for those.

For exterior objects like landscapes and trees, rocks etc. (textures in the "landscape", "architecture", and "terrain" subfolders) you can go close to them, but how much playing time are you going to be using staring at them up close? Those normal maps you can reduce to 1k without much visual difference, unless you go looking for it.

In general I do not recommend going below 1k ever... and never below 2k for weapons, armor and humanoid enemies, since those textures will become blurry messes (personal preference). Also the memory gained from going lower is so small compared from going to 2k to 1k that it just does not make sense...I also highly doubt that anybody can prove that going that low will help stability... since it frees up so very little. (5 MB to 1 MB compared to 1 MB to 300 KB for DXT5 compression roughly speaking.)

Body textures (usually in an actor/character/ subfolder) often contain a mix of compressed and uncompressed textures. For the tintmasks and any textures smaller than 512×512 it's best to process these using the contraints tab formats set to uncompressed lossless and the resolution limit set to be larger that than the largest resolution. Larger body textures, especially model space normal maps (files ending in *_msn.dds) and body models, can also be processed using these parameters butmauy also be possible to use the R5G6B5 lossy format without noticeable quality losses.

Seams are always going to be present; these are primarily due to the meshes. It would be a very time consuming project to sort these out, since not only would you have to fit the meshes with all possible other meshes that can be placed near them, you also have to sort it out with textures. Hence nobody really does this, and most of the time it is not that noticeable unless you stare at it.

Q5: How does DDSopt compare with Optimizer Textures

Optimizer Textures (OT) is another utility that can optimize textures in Skyrim and other Bethesda games. Its greatest advantages are that it is fast and fully automated. It is designed to:

optimize all the textures in a collection of BSAs (such as the vanilla Skyrim BSAs), placing the optimized textures into "Skyrim/Data/textures", or
directly optimizing all the loose file textures in the "Skyrim/Data/textures" directory.

Like OT, "DDSopt" can be used to optimize all of the textures in the "Skyrim/Data/textures" directory, but it is normally used to optimize mod textures before they are installed into Skyrim. Unlike OT, DDSopt can traverse the directory tree of mods and find and optimize the textures; it also copies all the other files in a mod to the output folder creating a duplicate of a mod with optimized textures. Once mods are extracted into loose files, DDSopt can also optimize textures from multiple mods at the same time thus simplifying the preparation needed before installing a set of mods. It can also optimize files from one or more BSAs simultaneously, but while doing this it can only write the output as a set of BSAs when doing this (unlike OT, it won't simultaneously extract and optimize).

The textures in the vanilla BSAs (Skyrim - Textures, the 3 HRDLC, and the 3 addon DLC) are almost all compressed (DXTx) and the high resolution textures in the HRLDC do not include many textures that have a large effect on VRAM use (e.g., exterior textures such as architectural, terrain, and landscape). OT can optimize the vanilla textures faster and more easily then DDSopt, while the quality of the textures from DDSopt is a little higher. DDSopt can be configured to optimize these textures to use less VRAM than the ones optimized by OT, but the difference is likely to be modest.

While the textures in the vanilla BSAs are improved when optimized, this is not always true for textures from other mods. There are many Skyrim mods that include textures created by experienced graphic artists, often with carefully crafted alpha channels, using high end texture creation tools. These textures are already highly optimized, and running optimizers like OT or DDSopt on these yields textures that are typically noticeably degraded from the original textures. Many of these mods have textures that replace lower resolution vanilla Skyrim textures, providing much better graphics quality in the game. Since these are replacement textures, it would be very difficult (and tedious) for OT to exclude these textures when optimizing the entire Data/textures directory. It is much more straightforward to selectively exclude textures from optimization processing before they are installed, and this is much easier with DDSopt as it is designed for optimization prior to installation.

As Skyrim users try to include more mods, and better quality textures, in their game load the limitations of the Skyrim game engine have become more apparent. Skyrim is a 32 bit game using DX9 textures. At the time of its release Skyrim was one of the few DX9 games that tried to make use of 2 GB (or more) VRAM. Many users have found that it is all too easy to exceed the VRAM available in their GPU. Moreover, Skyrim turns out to have another problem limiting how much graphics memory can be used in the game, even by users with large VRAM storage. Since it is a 32 bit game using DX9 graphics, for various reasons (including the use of DX9 vs. more recent version of DirectX) many of the textures are loaded in both RAM and in the GPU VRAM and unfortunately it is quite easy (and all too common) for these stored textures to cause the game to run out of available RAM (the 3.1 GB RAM limitation that is being widely discussed by Skyrim users) as well as VRAM. The only effective solution is reduce the texture load of the game; ideally this is done in a way that allows the game to maintain as high a quality graphics as possible. Texture optimization is clearly key to this process.

One way to reduce texture load is to change the resolution and/or format of the textures that are most responsible for RAM/VRAM use. There have been two major approaches to this:

running a texture optimizer over a large potion (or all) of the textures used in the game to reduce texture resolution by half (this is what I understand many of the users that rely on OT have done)
doing carefully planned optimization that selects which textures are optimized to lower resolution, which textures are untouched, and which textures are reformatted to a different compression type. The selection process is concerned with the a combination of quality or the game graphics and impact on graphics memory. Some textures, like a number of the clutter textures, can be resized but there is little value since they don't have any noticeable impact on graphics memory use. In contrast, architectural, terrain, and landscape textures have a significant effect on graphics memory use. The STEP team has been experimenting with these tradeoffs, using DDSopt because it is flexible enough to be used in this process and codifying the selection process in batch files that take care of the otherwise tedious sorting and selection.

Temporarily ignoring normal map textures, if all the textures being optimized are DXTx compressed and the textures do not have alpha channels or make fairly simple use of the alpha channel, then there isn't much difference in the quality between what is produced by OT and DDSopt optimization. DDSopt does have special processing for many of the less common uses of the alpha channel to maintain high quality versions of these textures while optimizing; in contrast the OT ini file excludes a number of these more challenging texture variants from being optimized.

Normal maps, sometimes called bump maps, provide significantly improved graphic appearance without requiring higher resolution models (meshes). Because of this improved appearance for a modest increase in memory, normal maps are used extensively when creating texture sets. Normal maps, however, are intrinsically very different than the color maps for which DXTx compression was designed, but in most cases DXTx compression is nonetheless used for them. Normal maps account for a significant portion of the texture storage needs; an individual normal map texture is often the same size as the corresponding color map texture. As an example, the textures in the vanilla BSAs (including the HRDLC and DLCs) use 13.5 GB. Not even counting the small 512×512 and smaller normal maps in Skyrim - textures and the DLCs, the normal map textures are 36% of this (4.8 GB). DDSopt has a unique compression scheme for normal maps that "pre-warps" the normal map in a way that the resulting normal map after DXTx compression, and later decompression, has much higher quality than if straight DXTx compression were used. Even Photoshop does not have a comparable normal map compression capability. The special handling of normal maps is probably the most unique feature of DDSopt.

Results from benchmark experimentation by the STEP forum participants on reducing VRAM use have shown that normal maps matter a lot. These tests showed that the most effective way to maintain good quality graphics while reducing graphics memory use is to use DDSopt to create reduced resolution, and in some cases reformatted (with uncompressed normal maps), normal maps. This experimentation has included systems across a wide range of performance capabilities from laptops through very high end PCs. The test setups included a large set of textures from the texture replacer mods responsible for much of the VRAM use with Skyrim when using high resolution textures. The results show a 10-20% improvement (decrease) in graphics memory use after using DDSopt to resize and recompress, and for some textures reformat, normal map textures.

The remaining question is how practical for most users to use DDSopt to provide these capabilities; OT is certainly much easier to use while DDSopt remains quite challenging for most users. Part of this is in using the DDSopt GUI with the large set of configuration options, and another is having clear instructions on what to do. A lot of recent effort by STEP participants has been on determining the processing steps, and associated DDSopt parameters, that should be used. In addition, the team has been working on automating the process so that the overall process is actually usable by most Skyrim users. We recently developed a new set of steps, and some batch files, that do much of the tedious work involved in optimizing the vanilla Skyrim textures using DDSopt. The next major step will be to extend this to provide a straightforward and reasonably simple way to optimize some of the key Skyrim mods with textures, concentrating on the core STEP mods that provide textures.

As mentioned in this forum post by a user who has played Skyrim with textures optimized by both of these tools and compared the results: "There has never been any doubt that Optimizer textures is more user friendly... but that friendliness comes at the price of quality.".

Q6: How should mods from Steam Workshop be used

A few mods are only available on Steam Workshop. The recommended approach for these is to subscribe to a mod on Steam Workshop, and when the mod is downloaded unsubscribe from the mod on Steam Workshop. If Mod Organizer is being used there are instructions for this in the Steam Installation Guide. The BSAs provided with mods from the Steam Workshop need to be extracted into loose files if the BSA has textures or other resources that could be overwritten, as mentioned in the previous sidebar.

If Wrye Bash is being used, any BSAs that are extracted into loose files should be removed from the Data directory. If the subscription to the mod is not removed on Steam Workshop, whenever the Skyrim launcher is used Steam will reload all of these BSAs and esp plugins and they will need to be removed again.

Q7: How does Optimization affect the use of the Creation Kit

There are two .ini files used by the Creation Kit, and these need to include the names of the vanilla Skyrim BSAs used in Skyrim. If Mod Organizer is not being used the SkyrimEditor.ini file in the Skyrim directory needs to be updated. In the section of the file under [Archive] the line starting with "SArchiveList" and the line starting with "SResourceArchiveList" should no longer have Skyrim - textures.bsa in the line.

Note that, as also mentioned in other STEP guides, if any DLCs are used these two lines should both contain the BSA file names for each DLC being used. This needs to be even when Mod Organizer is used.

Creation Kit expects any facial textures that mod creators use from the vanilla textures are unmodified, even if they are monocolor. If they are changed significantly by DDSopt they cannot be included in mods created using the Creation Kit. The batch file in this guide for sorting vanilla Skyrim textures ensures that these facial textures, typically 256x256, are unchanged. Ordinarily DDSopt would reduce monocolor textures to 1x1, as mentioned in the nex question.

Q8: What are Collapsed Textures and How are they Used

Ethatron's answer to this in the Technical FAQ is:

planar (1x1) textures - 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).

This reduction to 1x1 is called collapsing. While it is true that the graphic hardware almost always handles these properly, software textures creation and editing programs don't usually handle these. The batch files in this guide eliminate a small subset of the vanilla facial textures from optimization to prevent portions of these that happen to be monochromatic to be collapsed. There are many monocolor textures in the vanilla textures/terrain directory, and typically these can be collapsed without causing any problems with the game.