this sorta pertains to the dxt compression used in compressed dds texture. so its sorta useful information to have. i dont really want to start a dds vs tga debate, i just want to improve my understanding about how dxt actually works and thus improve my modding capability.
well everyone associates dxt with microsoft because its got dx in it. while in fact its really an s3 texture compression format format aptly named s3tc (duh). anyway i was trying to fix some problem with dos quake and ended up reading a ton of material regarding how texture compression actually works. i red that john carmack perfers to store some of the normal mapping uv data in the alpha and green channels of dxt5, rather than using a dxt1 or an uncompressed texture. this got me curious as to why. so i thought id look up how DXTx actually stores data.
first of all, all this time i though it was storing 8 bits a channel no matter what and just works some magic to make it smaller. i was wrong. seems that only a pair of 16 bit colors were stored in a 565 format per each block of 16 pixels. this came as a shock to me. because ive worked with 16 bit textures before and they are butt ugly. so i got even more intrested in what it was doing behind the scenes. how the hell does this look so damn good?
now there are only 2 colors actually stored for each 4x4 block. but then each pixel also has a 2 bit index value, a number 0-3 to indicate what pixel color to use. so essentially in stores each of these blocks as indexed color with each one being 1 of 4 different colors. now that would indicate that we should store 2 more pixel colors. rather than storing 2 more colors, the other 2 are interpolated based on the 2 that are stored. i messed around with a pen and paper trying to understand the math that was posted in the
wikipedia article. i think i got it but im not sure i got it right.
there are a couple formats which are mysteriously missing from the photoshop plugin, which are dxt2 and dxt4. these are counterparts to 3 and 5 respectively. the even numbered formats seem to have what is called premultiplied alpha, which if im not mistaken means that the rgb values are darkened according to alpha from the imput image and stored as opaque. i assume thees are legacy formats from around the time fs2 came out, when almost all transparency was additive. makes me question if these formats would be useful for beam rendering.
anyway the rgba -> dxt1 conversion process was sorta sketchy and pretty much remains a mystery to me. im not sure how the two 16 bit colors and the 2bit per pixel index came to be but i do know how they can represent 16 pixels. dxt1,2,3,4,5 all store opaque data in the same way. probibly using similar compression routines as photoshop would use for saving an 8 bit indexed image and probably storing the 2 colors from the source pixel with the biggest numerical gap. the 2 colors are selected are ones that actually get stored in the image file and are the first 2 slots of the 2 bit color table. the other 2 colors are calculated via interpolation. the first interpolated color is the sum of 2/3 of the first color in the table and 1/3 of second (this is done for each color channel separately and stored in the respective channel of the calculated pixel color). and the second pixel color to be calculated sums 1/3 of color 1 with 2/3 of color 2.
dxt1a is the exception. it has one bit alpha which is stored depending upon which of the first 2 colors is brighter. if the second color in the table is brighter than the first, then the 4th index is set as a transparent an any pixel flagged with that index is excluded from rendering. otherwise color data for the third and 4th index is stored as described above. the 3rd pixel is interpolated differently, by summing 1/2 of the color data from each of the first 2 colors which comes up with a color which is about average. this means that dxt3 would loose color information on any block with transparency. so you would loose
of color if just one of the pixels was transparent.
dxt3 simply cheats and stores transparency directly as a store a 4 bit transparency value for each pixel stacked on top. dxt5 on the other hand interpolates transparency in an even more complicated way than color. in addition to the 2 bit color table and 2 base colors theres also a 3 bit transparency table and an extra pair of 8 bit trans values. 3bit means 8 possible values. this also makes the transparent channel
more detailed than any one of the color channels, being based off of 8 bit values rather than 5 or 6 bit values.
anyway it starts with a color table with only 2 entries in it, 6 blank slots to fill. if the first alpha value is bigger than the second, then the other 6 alpha values are calculated by value (1*m + 1*n) / 7. n and m are 6 and 1 for index 3, 5 and 2 for index 4, 4 and 3 for index 5 and so on until the table is full. but if value 1 in the table is smaller than value 2 the values use a different formula. values 7 and 8 are not interpolated and are set to 0 and 255 respectively, leaving only indexes 3-6 to be interpolated. the formula is the formula is (1*m + 1*n) / 5 but replace m and n with 4 and 1 for index 3, 3 and 2 for index 4, and so on. same subtract from m and add to n for each index.
that answered my question about the dxt5nm format for normal maps. you use the alpha channel instead of red to store x, because the you have 8 shades of 8 bit transparency instead of maybe 4 shades of 5 bit red. green has an extra bit and keeps the y values while holding a better accuracy. im not sure if z is stored in blue, or if its not stored at all and calculated based off the x and y vales, or if the blue and red are put together to get a bigger range. anyway i answer a few questions about the mysteryous format and brought up a bunch more. i hope i was informative, you cant use a tool if you dont know anything about it.
