Can you even open DDS in MS Paint? Follow Mart's instructions on the previous page. The link for the Compressonator is in the OP.

It would be nice if this got stickied. Do the gamesas forums work like that? ;O Can you request mods to sticky a topic?

Yep. PM a moderator and they'll post a thread about it in the admin forum (if they agree) and it will be discussed. Takes a while though.

Not quite. 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.

PPS. IIRC, there are texture formats which supposedly handle normal maps better than DXT while offering a decent level of compression. It may require changes to Skyrim's shaders to make work, though.

You can also save normals as http://obge.paradice-insight.us/wiki/Modder%27s_Manual, raising precicion. You just have to have in mind that you can not go above ~60° if you clamp z to 0.5.

what i realy need to know is how to effectly make good quality normal maps... saving them as a dss is pretty straight forward as either a dxtc version or a 1/4 res raw format.

problem is almost every single tutorial is obsolete and typically doesn't give a good indication of how to get some serious height, most of them have resulted in the normal maps i've tried to create from a referrence texture file which nothing really standing out at all specially when compared to the original vanilla normal map.

Many of the normal maps come from high poly geometry baked to the low poly models. I don't know how much Zbrush they used compared to overlaying details in Photoshop. But a purely 2d generated normal map rarely compares to the depth of a geometry generated one.

Here's a good tutorial:
http://www.poopinmymouth.com/tutorial/normal_workflow.htm

As far as overlaying, I use this script now, the results are more accurate, but the idea is the same.
http://www.rodgreen.com/?p=4

Thankyou everyone for the amazing input. I've updated the OP with various posts and resource links quoted in these pages.


Maybe with Ethatron's tool we can do this.


DDSopt may do this for you, in the meantime seehttp://www.gamesas.com/topic/1330609-if-youve-released-a-texture-mod-or-plan-to-please-read/page__view__findpost__p__20012655.


I would like to know this too.

Why reservations? If the texture doesn't need an alpha, don't save one. Smaller filesize, smaller VRAM footprint, better all around. As Mart said in his OP, the *only* difference between the DXT formats is how the alpha channel is handled.


Yep, already said as much. Though without the details on what normal maps do...

Hey Mart, could TK's old Keep Details file be linked? TK, are those still valid?

Yep it's in your quote in the OP, but I've just added it to the Resources section too.

I'll take a gander... but unfortunately the only tool at my disposal at the moment due to trial periods having ran out, is photoshop.... The Nvidia DSS tool has a normal map maker.. but like i said.. doesn't seem to matter what tutorial i use to try and use nvidia's normal map maker to do it, results in total garbage/flat images with these little itty bitty specs essentially. And it doesn't matter what i use for height increases, doesn't seem to change.

I suppose i would have to send the texture off to someone with an actual 3D model to overlay the texture over and then create a normal map with. I wonder if anyone could offer to help with that.

Trying to make a good quality normal map with this

http://www.skyrimnexus.com/downloads/file.php?id=4408

This is the blame-thread, right?

http://www.skyrimnexus.com/downloads/file.php?id=5007 232.233.284 -> 179.021.716
http://www.skyrimnexus.com/downloads/file.php?id=329 223.703.808 -> 206.926.512
http://www.skyrimnexus.com/downloads/file.php?id=419 Perfect score! clean
http://www.skyrimnexus.com/downloads/file.php?id=2146 Has two truncated textures, otherwise okay
http://www.skyrimnexus.com/downloads/file.php?id=114 498.963.072 -> 396.900.920
http://www.skyrimnexus.com/downloads/file.php?id=3793 2.167.296.376 -> 1.400.695.720

I'm beginning to think it may be helpful for a dedicated thread for those. That way they won't get lost as easily...

Well, because I seemed to remember (which was obviously wrong) that there was a difference in the way transitions were handled by DTX3 and DTX5 in the textures themselves, but now that I found out that it only matters for the alpha channel it really doesn't matter anymore.

All the textures I've ever put out have been intentionally uncompressed, as all the compressions I've ever done with various programs have always come out being too off for me to be happy with them. With this Compressionater program, that isn't so. I see a very small (negligible, imo) loss in visual fidelity, and this thread has given me enough info to know what I'm doing. Thanks for posting this.

One thing I am wondering, though, is about the different options in relation to mip-mapping with that program. Which choice gives the best quality output? I'll probably check it out myself and I'll post something in relation, but keep in mind I'm just a monkey clicking buttons here and interpreting, I don't really know what I'm doing.

Edit: I figured by doing this I was just being nit-picky and I probably wouldn't notice too big a difference between the choices, but they do seem to come out quite different. They can generally be rated on a scale of crisp to smooth, and which you'd chose would probably depend more on what sort of texture it is than any of them being distinctly better than the others. I'd be inclined to say you could just stick to the default box-filter for a happy medium, and as another side note the D3DX point filter didn't work right for me. I'm only compairing one texture's mip-maps, though, so obviously you could look into this more, I just don't care to.

explicit alphas versus interpolated alphas is the only differences i saw between dxtc 3 and dxtc 5..

essentially interpolated alpha's produces an alpha channel that is much higher quality, less compression artifacts and splits the alpha into grids to do it.

One of the ways i was told that it's best to explain it is like taking a lossless file format.. lets say bmp... and then save it as a lossy file like a jpeg..... now take the same bmp and split it up into lets say 16 individual peices, save each peice as an individual jpeg, the result usually is that you'll get essentially the same file size when 16 are combined as the single jpeg... HOWEVER, the quality of the 16 peices together will produce a superior level of quality/detail compared.

Obviously though your not getting 16 individual files in the DSS however the interpolated DXTC5 will/should produce a better result.

I created an account here for the express purpose of thanking you for posting this topic. I sincerely hope every last mod author reads it and takes it to heart.

Did you just change all textures to dxt1 and kept all normals as dxt5?
Or are you using some sort of auto anolysis tool?

Here are some other mods that need to be compressed correctly:


High Resolution Armors Parts 1 and 2
High Quality Food and Ingredients
HQ Towns and Villages

This is great, im such a noob without knowing it. I have not released any mods but have played with textures a lot. Good resource!

I use http://www.skyrimnexus.com/downloads/file.php?id=5755.

Maybe you remember the problems NVidia hardware always had with DXT1, DXT3.

Using compressed textures with the first geForce cards (up to geForce 3 included) resulted in atrocious banding due to the card inability to correctly handle decompression. Afterwards, when ATi caught up wity NVidia during the days of the GeForceFX fiasco again NVidia resorted to handle DXT1-3 differently to gain some fps.

Speaking about tools to compress textures, despite the age, the best tool I ever used is a really old S3TC utility distributed in 1998 with the original Savage card. The way it handles DXT1 is unmateched by any other subsequent tool I've seen. Beats me why, since S3TC is really a simple lossy interpolation algorithm that stores 4 32bit pixels in 64bit of data.

I am not surprised. And I would be interested trying this tool. Do you know if it's available in any form nowadays? (What was its name?)

Here's why I am not surprised (and some people will already understand this, for example, if they had carefully read throttlekitty's references):

DXT compression handles colors by picking two colors, which are expressed using 5:6:5 bits (5 bits for red, 6 bits for green, 5 bits for blue). And then it uses two bits for each pixel -- for picking a color defined between the two reference colors. [And there's that sneaky little stunt that DXT1 uses for 1-bit alpha, which depends on the order of the two reference colors.] Anyways, this means that the maximum resolution under ideal circumstances for DXT compression is 7 bits for red, 8 bits for green and 7 bits for blue. And, this means that the worst case resolution is 2 bits for red, 2 bits for green and 2 bits for blue. Sort of...

Here's the trick, though: you can pick different reference colors to try to make the colors available from the two bits that specify each pixel "better fit" your image. As a "dumb simple first approximation" you can try all 4 billion possibilities of reference color combinations and measure the amount of error you would get by encoding the 16 pixels of the patch, and then pick the combination that produces the least error. But that's dumb, because no one should have to wait that long to save a file. Anyways, a "good compressor" has some opportunities for cleverness here. (The simple approach would be: find the brightest and dimmest color values, use them for the reference colors, then pick the best match for each pixel -- but what if you could get a better match for most of the colors by picking bounds that are farther apart, or closer together?)

(And there are different kinds of goodness -- a compressor for dxt textures that will be renormalized for use in normal maps would be totally different from one which is designed for imagery that a person will be looking at.)


Here's another trick: even though only 5 or 6 bits of color are specified, the colors are specified to 8 bit accuracy by taking the most significant bits of each color element and using them to fill in for the "missing bits". In other words the five bit color numbers look like this: (0, 8, 16, 24, 33, 41, 49, 57, 66, 74, 82, 90, 99, 107, 115, 123, 132, 140, 148, 156, 165, 173, 181, 189, 198, 206, 214, 222, 231, 239, 247 and 255). So if the compressor was assuming that the colors were evenly distributed it will sometimes be doing the wrong thing.

And here's another trick, and perhaps the most obvious (but still possible to get wrong). If you think of colors ranging from 0..1, the "1" corresponds to 255 and not 256 -- if the compressor is coded with the assumption that 256, 256, 256 corresponds to white that could be bad. (I do not know of any compressors which make this mistake -- and it seems extremely obvious -- but I think it could be an easy mistake to make if someone is trying to write "efficient code". Personally, though, I have made dumber mistakes when I have written programs, and this one would not be fatal, so it could easily get into released code.)

Anyways, I am not surprised to hear that some dxt compression algorithms do better than others.

My favorite is still nVidia's http://origin-developer.nvidia.com/object/texture_tools.html, I think it's the best available compressor out there.

DDSopt and nvtt both use squish, there wouldn't be any difference.