Normal map compression
admin
Howdy.
I wonder if any of you are using compressed normal maps?
We're about to start supporting it in our engine. For a 256x256 map, it's a filesize savings of like 55%... 192Kb for 24bit TGA vs. 86Kb for DXT5.
So I've been talking with Doug Rogers, developer relations guy at Nvidia, about how the DXT5 format is used for this.
So far, I'm hearing that you store the normal map X axis (what was in the Red channel) into the Alpha channel, and the Y axis stays in the Green channel, then you duplicate the Y into both the Red and Blue channels as well. The Z axis is computed in the shader, so it doesn't have to be stored in the bitmap.
Apparently, the DXT compressor works best with redundant values for R and G and B, which reduces compression artifacts. The way I understand it, DXT5 compresses every 4x4 block of pixels by storing only two color values, then using a 3D spline to store the other 14 colors as points in between the two extremes. So, the RGB channels need to be similar so the 3D spline can accomodate all 16 colors without missing some.
Seems like such a waste of those two "extra" color channels, but when I try a test like adding height data to the Blue channel, I get some ugly compression blocks... some blocks of the RGB channels flatten out to a solid color.
Alpha stays cool though. I wonder if this is because it uses its own 16-color 4x4 blocks, compressed/stored separately from the RGB blocks?
I wonder if any of you are using compressed normal maps?
We're about to start supporting it in our engine. For a 256x256 map, it's a filesize savings of like 55%... 192Kb for 24bit TGA vs. 86Kb for DXT5.
So I've been talking with Doug Rogers, developer relations guy at Nvidia, about how the DXT5 format is used for this.
So far, I'm hearing that you store the normal map X axis (what was in the Red channel) into the Alpha channel, and the Y axis stays in the Green channel, then you duplicate the Y into both the Red and Blue channels as well. The Z axis is computed in the shader, so it doesn't have to be stored in the bitmap.
Apparently, the DXT compressor works best with redundant values for R and G and B, which reduces compression artifacts. The way I understand it, DXT5 compresses every 4x4 block of pixels by storing only two color values, then using a 3D spline to store the other 14 colors as points in between the two extremes. So, the RGB channels need to be similar so the 3D spline can accomodate all 16 colors without missing some.
Seems like such a waste of those two "extra" color channels, but when I try a test like adding height data to the Blue channel, I get some ugly compression blocks... some blocks of the RGB channels flatten out to a solid color.
Alpha stays cool though. I wonder if this is because it uses its own 16-color 4x4 blocks, compressed/stored separately from the RGB blocks?
Replies
But I get artifacts anyway, as StrangeFate pointed out.
Tried a test, in case anyone's interested...
Yuck.