FXT1 explained
FXT1 is a texture compression scheme for 3D graphics, invented by the hardware vendor 3dfx Interactive and offered as an open source rival standard to S3TC in September 1999, a year after S3TC had been adopted by Microsoft as part of DirectX. Limited vendor hardware support has been a barrier to its acceptance. Notably, despite being open source, FXT1 was not adopted by Nintendo for the GameCube, nor by Sony for the PlayStation 3, in both cases losing out to the established S3TC standard. Another possible reason for its lack of adoption is that the CC_MIXED mode (see below) probably infringes the S3TC patent .
Four different compression algorithms are used by FXT1, chosen at a block level to optimize visual quality. Having to select an optimal path for each texture ensured FXT1 was relatively slow at compression, making it unsuitable for real-time compression in applications.
The original white paper did not follow well-known scientific rules, being actually a commercial presentation. The lack of theoretical guidance from the inventors might have been the cause of badly optimized compression scheme selection code, and despite potentially better performance due to four available compression schemes instead of one (as in S3TC), FXT1 did not show any quality improvements to S3TC, being inferior to it in most test cases.
In hindsight, FXT1 might have been more successful if 3dfx spent more effort examining optimization of the CC_MIXED compression mode, more similar to S3TC, and dropped the other three codecs from the standard. 3dfx was subsequently taken over by Nvidia who have continued to support S3TC as their preferred compression tool.
Compression algorithms
Four different compression algorithms are set out in the original white paper:
- CC_MIXED (similar to other S3TC): A 4x4 texel block is represented by two bits-per-texel for opaque textures. Additionally, each block has two 16-bit colors stored in an RGB 565 format. The two RGB 565 colors and two additional colors (created by interpolating between the two RGB 565 colors) form the primary colors for this texel block and its associated four color lookup table. A 2-bit index is used to determine which color from the lookup table will be used for each texel in the 4x4 block. Transparent textures are created by making one of the four colors transparent.
CC_HI (best for spatial resolution): A 4×8 texel block is represented by three bits-per-texel for opaque and transparent textures. Each block stores two 15-bit colors in an RGB 555 format. The two RGB 555 colors and five additional colors (created by interpolating between the two RGB 555 colors) form the primary colors for this texel block. Additionally, an eighth color is defined to be the transparent color. A 3-bit index is used to determine which color from the 8-entry lookup table will be used for each texel in the 4x8 block.
CC_CHROMA (good at complex color areas): A 4×8 texel block is represented by two bits-per-texel for opaque textures. Each block stores four 15-bit colors in an RGB 555 format. All four colors are used directly with no interpolation to form a 4-entry lookup table. The 2-bit index assigned to each texel in the block is used to determine which of the four colors is assigned to each individual texel. Note that Colors4 only applies to opaque textures, as it does not support transparency.
CC_ALPHA (gives the best control over complex alpha transparencies at four bits-per-texel): A 4×8 texel block is represented by two bits-per-texel for opaque and transparent textures. Each block stores three 20-bit colors stored in a 5555 format. The first and second 20-bit colors are used for the primary colors of the left 4x4 block, while the second and third colors are used for the primary colors of the right 4×4 block. Two additional colors are created in each block by interpolating between the two primary colors for that block. A 2-bit index is assigned to each texel in the block and a lookup table is used to determine which color is applied to each texel.
See also
References
