1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
# Texture Compression
## S3 Texture Compression (S3TC)
See S3TC.
## ATIMach64 / ATIR128 texture compression
According to an ATI press release:
* _3D RAGE PRO supports several methods of texture compression, including use of palletized textures, with VQ permitting 8:1 compression, allowing content developers to produce richer content without limits on texture size. Texture compression technology and the ability to share host memory gives the developer more memory to work with when handling complex textures and removes the need to write complicated texture management schemes._ -- [[IanRomanick|IanRomanick]]
This is something interesting that I had also noticed when reading the chip specs, a TEX_COMPRESS bit that enabled 4:1 VQ compression. (the 8:1 must be with palletized textures simultaneously). At that time I didn't fully understand what was the meaning of this so I left this for a later time.
* -- [[JoseFonseca|JoseFonseca]]
I took a peek at the ARB_texture_compression extension. New internal format tokens would need to be created for each of the compressed formats available. So, if only compressed RGB textures are supported by the hardware, then something like GL_COMPRESSED_RGB_VQ1_MESA would need to be added. Then, when a texture is sent into the driver, if the texture format is non-compressed (i.e., GL_RGB) and the internal format is either GL_COMPRESSED_RGB_VQ1_MESA *or* GL_COMPRESSED_RGB, the driver would need to compress it. If the texture format is already GL_COMPRESSED_RGB_VQ1_MESA (very, very, very, unlikely), it would just get passed through.
Now, the new token could probably be skipped. If the requested internal format is GL_COMPRESSED_RGB, just compress the texture and be done with it. Given the likely hood of ANYONE having pre-compressed textures for this format, this is probably both the easiest and best route to take. This is amplified by the fact that I don't think that even the ATI drivers export this functionality in OpenGL. Does anyone know any different?
Perhaps we could discuss this more in the IRC chat today.
[[http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt|http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt]] [[http://oss.sgi.com/projects/ogl-sample/registry/3DFX/texture_compression_FXT1.txt|http://oss.sgi.com/projects/ogl-sample/registry/3DFX/texture_compression_FXT1.txt]] [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt]]
* -- [[IanRomanick|IanRomanick]]
While I was searching around the net for papers on texture memory management, I came across some references to Talisman and DirectX 6.0 texture compression. It seems that the compression algorithm used is called "TREC," which is short for "Texture and Rendering Compression."
[[http://www.ubicom.tudelft.nl/docs/UbiCom-TechnicalReport_1998_6.PDF|http://www.ubicom.tudelft.nl/docs/UbiCom-TechnicalReport_1998_6.PDF]] [[http://research.microsoft.com/MSRSIGGRAPH/96/Talisman.htm|http://research.microsoft.com/MSRSIGGRAPH/96/Talisman.htm]]
Apparently, it is some sort of DCT based compression scheme. That would explain why ATI is the only company to ever implement it in hardware. :)
* -- [[IanRomanick|IanRomanick]]
According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info. Rage 128 also has a VQ texture format bit, according to the register header file. Sega dreamcast used a form of VQ compression also, I think.
* -- [[LeifDelgass|LeifDelgass]]
## General resources
[[Image Compression with Vector Quantization|http://www.gamasutra.com/features/20010416/ivanov_01.htm]] (registration required) has a fairly extensive description to VQ (vector quatitization) encoding, including sample code. It actually distuinguishes VQ from DXTN (which is S3TC).
|
