DXT compression - how it works, why it produce 'ugly boxes'
Posted: 12.07.2003, 21:59
Hi all,
I think all (expect Fridger) who build normal maps and save this in DDS format (dxt1 or dxt3) made this stupid experience of the 'ugly boxes' (artifacts). I have searched a longe time to find the reason for this artifacts. Now I'd thought the compression software is the problem. Since David Brady build a Win version of 'Devil' I could test this and see that this tool produce also the 'ugly boxes'. The 'Devil' algorythmus works a bit different than NVdxt and this causes some small differences between the DDS files.
Now I searched for more informations about dxt texture compression and found this site.
The first link is about dxt1 compression and shows also how the color compression is made for dxt1, dxt3 and dxt5.
http://msdn.microsoft.com/library/en-us ... xtures.asp
The second link explain how the alpha channel is saved in dxt3 and dxt5 format.
http://msdn.microsoft.com/library/en-us ... annels.asp
Note: dxt2 or dxt4 compression is not relevant for us.
Ok what's the point. The compression format divides texture maps into 4x4 texel blocks. ( -> this is exact the size of the 'ugly boxes'! ). Each block contains two 16 bit 'extreme' colors and two further colors are derived from these stored colors by linear interpolation. That means there are only four colors within one texel block (can be checked with my example picture). The (theoretical) maximum color depth is only 17,5 bit (I know there is no half bits
but I think you know what I mean ). Another point is there is no difference of color compression between dxt1c and dxt3 or dxt5 format. A bug in the Nvidea hardware cause the differences that we know. This should be solved with the GF fx cards.
The trick is that this compression works good with most pictures and photos. A feature of a commen pictures is that the single color channels (red, green, blue) are relative similary. The problem is that a normal map does not belong to this kind of picture. The red, green and blue channel contain complete different data. Red is used for horizontal shadows and lights while green stores the vertical shadows and lights. The blue channel can be used for the brightness of the base texture. This is only usefull if the main texture is complete flat. I prefer to fill this channel complete with white.
Ok here is a simple example of a bump map with it's normal map and the red and green channel of the normal map.
I hope the mystery of normal maps is now solved ?
Let's see what happens with a dxt compressed normal map. We know that within a 4x4 texel block are only two independent and two interpolated colores possible. But it happens that both color channels (red and green) contains informations but we need too the 'no effect' color for flat (unbumped) areas. Now it happens that this 'no effect' color is not part of the 4 possible colors. The result is that the hole texel block gets an bumpmaping effect and we can see this as 'ugly box'.
Ok I think that's enougth theory now some example pictures. The picture is a very small part of my 8k mars normal map. I've used a large zoom and a grid to show the 4x4 texel blocks. The left picture is the uncompressed one the picture in the middle is dxt1c compressed and the right one is a 8 bit palleted (256 color) picture.
Count the colors in the middle picture. You will never find more than four colors within one 4x4 texel block ! Look carefully and you can also find some compression artifacts.
The next picture is only the red cannel of my example. I used the NVdxt tool for compression. This favor the green color and therefore the red channel owns the most artifacts (Check the middle picture).
And now the green channel. The green valence of NVdxt causes that this looks relativ good despite the 4 color restriction (middle picture).
I have also tested the dxt compression by 'Devil'. This use another method to determine the 'extreme' colors and green is not favored. As a result the artifact can be found in all color cannels.
What has this 8 bit palleted (256 color) picture to do with the 'ugly boxes' ? Now this is my solution for the problem. There is a 8 bit palleted DDS texture format which is support by hardware. This format has the same size than a dxt3 or dxt5 compressed file and supports also mip maps. But this format is not supported by Celestia.
Chris, can you add this DDS file format to Celestia?
I asked this already some weeks ago in another post but I hope now this "little" post has enought arguments to do that.
Bye Jens
I think all (expect Fridger) who build normal maps and save this in DDS format (dxt1 or dxt3) made this stupid experience of the 'ugly boxes' (artifacts). I have searched a longe time to find the reason for this artifacts. Now I'd thought the compression software is the problem. Since David Brady build a Win version of 'Devil' I could test this and see that this tool produce also the 'ugly boxes'. The 'Devil' algorythmus works a bit different than NVdxt and this causes some small differences between the DDS files.
Now I searched for more informations about dxt texture compression and found this site.
The first link is about dxt1 compression and shows also how the color compression is made for dxt1, dxt3 and dxt5.
http://msdn.microsoft.com/library/en-us ... xtures.asp
The second link explain how the alpha channel is saved in dxt3 and dxt5 format.
http://msdn.microsoft.com/library/en-us ... annels.asp
Note: dxt2 or dxt4 compression is not relevant for us.
Ok what's the point. The compression format divides texture maps into 4x4 texel blocks. ( -> this is exact the size of the 'ugly boxes'! ). Each block contains two 16 bit 'extreme' colors and two further colors are derived from these stored colors by linear interpolation. That means there are only four colors within one texel block (can be checked with my example picture). The (theoretical) maximum color depth is only 17,5 bit (I know there is no half bits
but I think you know what I mean ). Another point is there is no difference of color compression between dxt1c and dxt3 or dxt5 format. A bug in the Nvidea hardware cause the differences that we know. This should be solved with the GF fx cards.
The trick is that this compression works good with most pictures and photos. A feature of a commen pictures is that the single color channels (red, green, blue) are relative similary. The problem is that a normal map does not belong to this kind of picture. The red, green and blue channel contain complete different data. Red is used for horizontal shadows and lights while green stores the vertical shadows and lights. The blue channel can be used for the brightness of the base texture. This is only usefull if the main texture is complete flat. I prefer to fill this channel complete with white.
Ok here is a simple example of a bump map with it's normal map and the red and green channel of the normal map.
I hope the mystery of normal maps is now solved ?
Let's see what happens with a dxt compressed normal map. We know that within a 4x4 texel block are only two independent and two interpolated colores possible. But it happens that both color channels (red and green) contains informations but we need too the 'no effect' color for flat (unbumped) areas. Now it happens that this 'no effect' color is not part of the 4 possible colors. The result is that the hole texel block gets an bumpmaping effect and we can see this as 'ugly box'.
Ok I think that's enougth theory now some example pictures. The picture is a very small part of my 8k mars normal map. I've used a large zoom and a grid to show the 4x4 texel blocks. The left picture is the uncompressed one the picture in the middle is dxt1c compressed and the right one is a 8 bit palleted (256 color) picture.
Count the colors in the middle picture. You will never find more than four colors within one 4x4 texel block ! Look carefully and you can also find some compression artifacts.
The next picture is only the red cannel of my example. I used the NVdxt tool for compression. This favor the green color and therefore the red channel owns the most artifacts (Check the middle picture).
And now the green channel. The green valence of NVdxt causes that this looks relativ good despite the 4 color restriction (middle picture).
I have also tested the dxt compression by 'Devil'. This use another method to determine the 'extreme' colors and green is not favored. As a result the artifact can be found in all color cannels.
What has this 8 bit palleted (256 color) picture to do with the 'ugly boxes' ? Now this is my solution for the problem. There is a 8 bit palleted DDS texture format which is support by hardware. This format has the same size than a dxt3 or dxt5 compressed file and supports also mip maps. But this format is not supported by Celestia.
Chris, can you add this DDS file format to Celestia?
I asked this already some weeks ago in another post but I hope now this "little" post has enought arguments to do that.
Bye Jens