|
Posted by
Toby Crundwell
on August 09, 2001
Company: Abit
Product: Siluro
MX400
Texture compression (S3TC/DXT1/DXT3)
Thanks to Thomas for sorting for the
following information
N.B. S3TC=DXTC, albeit DXTC is used in
Direct3D while S3TC is used in OpenGL, although other than
that no differences exist, both use the same 5 Compression
algorithms.
Texture compression is exactly as the
name suggests, a way of compressing textures, which in turn
increases the frame rate with (hopefully) minimum loss of
texture quality. The MX400 supports DXTC & S3TC texture
compression modes, although disappointingly the GeForce 2
family was allowed to inherit the same fault the Geforce 256
had. This fault being in relation to DXT1 compression. The
problem is that in DXT1 the MX 400 uses only 16-Bit
interpolation, while other graphics cards use higher
interpolation depths. As a result any DXT1 compressed
textures with the MX400 (or any other GeForce card, including
the GeForce 3) look hideous. The most commonly used example
to illustrate this is the sky in Quake 3.
A workaround of sorts however does exist
for this problem in OpenGL only. The nVidia driver team
added a workaround whereby DXT1 requests are changed to DXT3
instead. It must be stressed this is a workaround only &
that DXT3 offers poorer a compression ratio than DXT1. The
screenshots below illustrate the Quake 3 sky with Texture
compression disabled, then Enabled without the DXT3
workaround in effect, and then with DXT1.
This is a screenshot of a Quake III map
taken without any texture compression.
This is a screenshot was taken with DXT3
enabled.
This screenshot was taken with DXT1
enabled.
The screenshots are fairly self
explanatory as you can see, with DXT1 the sky is quite
simply messed up.
On Sharkyextreme
nVidia made some statement on the matter, that being
"It works according to spec". This is partially
true as the DXTC
spec makes no mention of what interpolation to use for
DXT1, but anyone with a basic sense of logic can figure out
that in order for Texture compression to be viable it must
compress textures with a minimum amount of perceivable
artefacts, something which nVidia has failed to pick up on
sadly.
While probably sounding a bit far
fetched, we may well think that nVidia's consistently poor
Texture Compression implementation is nothing more than a
semi-subtle attempt to get us to buy graphics cards with
consistently higher amounts of video memory, thus
eliminating the need for texture compression. It seems we
can only hope that the next Geforce graphics card resolves
this issue (Something we've been hoping since the first
Geforce was released).
Second generation Hardware Integrated
Transform and Lighting (H/TnL)
H/TnL theoretically massively improves
frame rates. It acts to take some of the TnL instructions,
mathematics, or vectors away from the CPU and put use the
GPU to calculate them, freeing up the CPU. However, it
suffers from several drawbacks. Most importantly, games (or
more specifically their graphics engines) need to support
it, and only newer games do this. Secondly, CPUs are now so
powerful that much of the advantage is lost. Thirdly, the
instruction set is static & still somewhat limited
despite being "2gen". The CPU (or more accurately,
the FPU) still gets a lot of vectors to work out before the
Siluro can render a scene even if H/TnL is enabled. The TnL
unit on the MX400 chip is also responsible to some degree
for FSAA, when it is enabled.
|
