Introduction

Nowadays 3D technology develops too quickly. A lot of new goodies appear every half a year, and a usual users simply have no time to keep an eye on what's going on. Companies show different demos based on new technologies where everything is cool and beautiful, but the games with such programs are still lacking.

One of the most interesting innovations in the world of domestic/game 3D graphics are the technologies of texture compression, which have become popular because of increased demands to texture size. With the increasing need in detailing in games and with spread out of 32-bit rendering we see now necessity in big 32-bit textures and consequently in extending of texture memory. Only Truecolor needs 2 times increased video memory and 2 times higher bandwidth of video memory. So, the manufacturers have faced a problem, that is how to extend texture volume without increasing a local memory of video cards. And now they see a wayout in texture compression technology. The first company that succeeded in this field was S3 Inc. which named her invention as S3 Texture Compression (S3TC).

Some very popular games have already been using such compression: Quake 3 Arena + games on its engine (Heavy Metal F.A.K.K. 2, Star Trek: Elite Force and others that will appear soon), Unreal Tournament, Soldier Of Fortune. In these games 16MB/32MB of local memory is not always sufficient, especially with 32-bit mode and textures in use. If anybody hopes for AGP - it makes no sense, only future versions might help here.

It's exactly compression support that made possible higher detailing in some games. For example Unreal Tournament on Savage via their own API Metal (and on some other video cards via new-made OpenGL driver), different special levels for Quake 3.

Just to show you I put here two screen shots where rendering is shown at standard texture resolution and at 4 times increased one and then S3TC compressed. But the requirements to the bandwidth and texture memory are either the same or even less for the second!

256X256 without compression	512X512 with compression

I guess everybody would agree that the right picture is much distinct.

From appearing of S3TC and until some time the texture compression was available only for S3 Inc. video chips, but then there was nothing for S3TC to compete against. Only much later there appeared the only competitor on the market - FXT1 technology from 3dfx Interactive, Inc. Well, with its release the developers received a possibility to choose, though only among two. And they will likely to stop at S3TC since it's spread widely and its version in DirectX is available for everybody. Besides, for compression application in OpenGL it is licensed by all main manufacturers of video chips (NVIDIA, ATi, and looks like that 3dfx do it also), and they have applied it in the soft hardware. Well, it seems that 3dfx has no more power to compete - nobody uses its compression format.

Running ahead I'd like to mention that FXT1 differs mainly in high compression coefficient. Since the algorithms of the formats are very similar, I suppose that higher compression was reached at the expense of quality loss. Let's check it.

In order to use all advantages of S3TC, we have to use the following popular video cards (or the video cards based on the video chips):

• S3: Savage 3D, Savage 4, Savage 2000
• NVIDIA: GeForce 256 (SDR and DDR), GeForce2 (GTS and MX, Ultra, Pro, and looks like Go as well), Quadro 1/Quadro 2 (MXR and Pro)
• 3dfx: VSA-100 (Voodoo 4 4x00, Voodoo 5 5500, Voodoo 5 6000)
• ATi: ATi Radeon (SDR and DDR).

For FXT1 we should use only 3dfx mentioned cards, but since the algorithms are practically identical, I think that this technology will be easily included in drivers of chips of other manufacturers.

Test conditions

The test computer is Celeron 450(4,5*100)/Chaintech 6ZIA(ZX)/96 MBytes PC-100/Quantum Fireball Plus KA 9,1 GBytes/Windows 98 Second Edition

These data are practically of no importance however, since we will pay attention mainly to the quality.

The test was carried out theoretically, that is without real games, since under real conditions much depends on optimization of texture compression support in the drivers of definite video cards and even chips. There is no games which support both technologies. Therefore we compared them with the help of utilities which are supplied by the both companies for developers. They have to be equipped with a reference coding/decoding at good optimization of speed.

When working with FXT1 we used utilities for developers from 3dfx of 09.14.1999. Their native name is "3dfx FXT1(TM) Texture Compression Binaries and Source Code".

For compression and unpack with S3TC we used utilities from a former company S3 Inc. - "S3TC Utility/Viewer 1.1". For the utilities refer here.

For conversion from/to 16- and 32-bit Targa formats with quantization and different methods of dithering we used an old though rather convenient graphics viewer for DOS: Sea 1.3. It ensures decent quality of dithering for two methods.

In the test we used 2 sets of textures:

1) Selected textures of demo version Quake 3 Arena 1.11, in different formats - JPEG and Targa, overall 10 in number. Different types were taken: with color blending, usual textures of walls, floor, one texture of sky and personage model.

The list of original names and ways:

pak0.pk3\textures\gothic_block\blocks15.jpg
pak0.pk3\textures\gothic_floor\blocks17floor3.jpg
pak0.pk3\textures\skies\inteldimclouds.jpg
pak0.pk3\textures\liquids\kc_fogcloud3.jpg
pak0.pk3\textures\base_wall\patch10_beatup2.jpg
pak0.pk3\textures\gothic_floor\q1metal7_99.jpg
pak0.pk3\gfx\misc\teleportEffect2.jpg
pak0.pk3\models\mapobjects\baph\baphomet_gold.tga
pak0.pk3\textures\skin\chapthroatooz.tga
pak0.pk3\models\players\major\daemia.tga

For visual comparison we provide here only 3 textures: inteldimclouds.tga, teleportEffect2.tga, chapthroatooz.tga. There you will clearly see all lows of compression.

2) Set of 10 test textures collected with the purpose to determine weak points of texture compression. They are not typical texture fragments for games. For example images with a lot of colors, with gradual and abrupt color changes etc. As preliminary tests and real games (Q3) showed, compression performs the worst way here.

For visual comparison we chose only 3 textures: topsmap.tga, reference.tga, abstrwav.tga.

The texture pixtest.tga was out of the competition since it looked completely different from the present textures. It was used as the most original and the "difficult" one.

Note that all textures are of the same size - 256X256 - in order to make the test easy and receive the most exact results. Of cause, compression technologies are used mainly for large textures, but we took 256X256 textures for convenience and smaller size.

All the textures were converted in 32-bit Targa format with alpha-channel, since 3dfx utilities don't know other formats. From those textures which had the alpha-channel from the very beginning, this channel was deleted to provide equal conditions for comparison of 16-bit textures and those which were S3TC and FXT1 compressed.

So, for comparison we took 16-bit textures obtained by quantization (color reduction) of original ones to 16 bit with usage of 2 methods of dithering and without it. For visual comparison we took only 16-bit textures with floyd-steinberg dithering, since they give the best results among 16-bit images. Notice that in games they usually use quantization without dithering or with ordered dithering. That's why the chosen quality of 16-bit textures is the maximum possible.

Later we converted these textures back in 32-bit format.

Compression utilities application:

• FXT1 Compression

encode image.tga image.fxt
• FXT1 Unpack

decode image.fxt image.tga
• S3TC Compression of several images

s3tc *.tga
• S3TC Unpack

The quality of the source and received images was compared with 3dfx utility:

• isub –v image.tga image_fxt.tga difference.tga

In the result of executing of difference.tga we received a file. Mostly we were interested in Root Mean Square (RMS) error. It shows the quality of image compression with data loss. The less the value, the better the compression quality.

Only for visual comparison from the middle of each obtained image of selected 6 textures we cut out a part 128X128 in size and then doubled it, that is up to 256X256, and then it was compressed in JPEG with the quality of 85. The scaling was applied to let us see all disadvantages.

Compression and unpack speed

Compression speed depends on many factors (code optimization, compression method) and greatly differs for various methods. Developers haven't to compress textures often, if the game use the compressed textures from the very beginning. For example, S3TC managed to compress complex (with rear recurring pixels) textures 256X256X32 for about a couple of seconds, and 3dfx baby did the similar thing for about 50-60 seconds on the test computer. I understand that the compression of 3dfx is advanced, it chooses the format out of several possible and so on, but the shown low speed says that FXT1 compression code has a long way to go in order to optimize its speed.

It's quite difficult to say something definite on the decompression speed: at the first look the textures were decompressed rather quickly on the test computer. The main thing is that the decompression should have a decent speed with the definite hardware and drivers. All the manufactures who realized "hardware" texture decompression can boast of good speed.

Texture compression degree

Compression can be without data loss (LZW, Huffman and other types and methods which are used in archivers, GIF and PNG graphics formats) and with data loss (JPEG, MPEG, modern audio codecs).

Both considered technologies provide compression with data losses. The matter is that the losses must be slight and practically unnoticeable. For example, JPEG photo with the quality higher than 85 at 800x600 and higher on 15" monitor would look identically to the original.

Don't be afraid that you could see any artifacts when watching closely a compressed texture. With a good realization of compression/decommpression and with large textures one texel of uncompressed texture will be replaced by several (4-8) compressed ones.

General principles of compression are similar for the both technologies. Texture compression degree is constant: for FXT1 it's 8x compression with alpha-channel, and for S3TC it makes 4x with alpha and 6x without or with simple alpha-channel. For instance, 256x256x32 texture with alpha-channel is compressed from 256 KBytes to 32 with FXT1 and to 64 with S3TC. Well, if S3TC compresses 4 times, then 3dfx compresses 2 times more the size of 32-bit texture in the memory!

Well, we can clearly see the leader here, but does it provide better quality as well? Let's check it.

Compression quality

Do you remember what we chose for determining of compression quality? Yes, that's right, RMS. In order to find out sensitivity to image artifacts there you can see the numbers for the same textures compressed with JPEG with quality 85, and then converted back to Targa. If you are interested in the size of resulted JPEG's, they were from 5 to 30 KBytes, what is much less than 32 KBytes of FXT1 and moreover 42 KBytes of S3TC.

The ratio FXT1/S3TC shows how worse (in percentage) is the number RMS when using FXT1 as compared with S3TC.

Game textures:

Test textures:

S3TC beats FXT1 in terms of quality, but both take a leap in front of 16-bit formats without dithering and with ordered dithering, and both again lag behind 16-bit with floyd-steinberg dithering.

Interestingly that FXT1 outperformed S3TC only in two cases (kc_fogcloud3.tga and topsmap.tga), but again running ahead I'd like to mention that visual compression quality of S3TC is still better!

Compression quality: visual representation

Unfortunately, the pictures in uncompressed 32-bit format are impossible to be put here because of their huge size, but you could have seen more vivid quality losses.

In these pictures you can see losses followed compression or quantization.

chapthroatooz.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

This is one of the textures where FXT1 has rather decent quality. Similar textures take the most part in games, but there are some others. The following examples reflect them.

inteldimclouds.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

On the 16-bit textures you can notice a strong grid, though it's quality is quite good for 16-bit. For FXT1 you might see rather strong banding, and S3TC has it much weaker.

teleportEffect2.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

For 16-bit the texture performs good, and FXT1 again seems to have difficulty with gradients, S3TC quality is moderate but closer to 16-bit. Let's see what will happen with test images. For now I mark FXT1's lag.

abstrwav.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

First the quality of 16-bit is very close to 32-bit texture, but second - both formats have strong similar disadvantages - the spaces with close colors turned to monotonous spots. FXT1 reached worse quality than S3TC.

reference.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

16-bit demonstrates a vivid grid. S3TC quality is better, the banding is hardly noticeable. FXT1 has stronger problems - the textures seems to be divided in squares.

topsmap.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

It's interesting how FXT1 managed to win over S3TC at quality factor in this image? As I can see the FXT1 compressed texture is much worse. With S3TC the image became a bit greenish, probably this is the reason that it lost when compressing this gradient texture. To tell the truth, RMS counts the sum of colors differences. But in any case FXT1 looks worse than S3TC.

And the last one - an image that didn't enter the main group. It's generated synthetically and differs much from usual things used in games.

pixtest.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

In this case 16-bit texture is a leader. And among the other technologies FXT1 is a bit ahead, but in case of FXT1 there is a lot of purple/pink, and the contestant has again greenish picture.

Conclusion (visual comparison)

• 16-bit is good in many cases but there is practically always a grid and bad representation of gradients.
• S3TC has decent quality almost in all cases but for the last one, better representation of gradients.
• FXT1 is an evident loser, bad representation of gradients, quite strong banding, worse detailing.

Now we are passing to pictures which were obtained after image processing with isub.exe utility and after filter "strong edge detection" processing to let us see at least anything.

I recommend you to set the brightness of your monitor to maximum in order to see all artifacts.

chapthroatooz.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

It looks like 16-bit texture won here. Among the others S3TC is leading, FXT1 is the "noisiest".

inteldimclouds.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

If 16-bit shows strong stains, S3TC and FXT1 don't offer such. Though they both have some artifacts.

teleportEffect2.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

16-bit dithering picture looks the worst of all. S3TC wins over FXT1 by a margin of approx 20 %.

abstrwav.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

FXT1 performs bad again.

reference.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

S3 compression shows good results winning over 16-bit texture. FXT1 lags behind the first one, though it wins over the second.

topsmap.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

16-bit is out the competition - falls behind all of them.

And here FXT1 is worse than S3TC for this texture.

And at last, you can see the test image that didn't enter the base group.

topsmap.tga

32-bit	16-bit with floyd-steinberg dithering
S3TC	FXT1

Here is an explanation for the bad result of S3TC. What a beautiful image :) Why so much pink? It's simple - it means that S3TC has different precision in rendering of colors. For green it it higher. And FXT1 has quite equal losses of all colors, but big as well. The winner was known beforehand here - 16-bit texture without the limitations which are present in both contestants: small number of possible colors in each unit of 4X4 pixels in size.

You can see that the compression formats of the competitors are quite similar though differ in precision. S3TC performed better in terms of quality than FXT1, this method outdid 16-bit format, and FXT1 was close to its best sample.

The competitors have different losses, though the dependencies are quite similar. The greatest problems concern the textures which possess small spots with gradual color change, after conversion they become the spots of one color and there appears some kind of banding. And as for textures of ground, walls, stones, bricks, doors, windows and others which make the main part of 3D games, everything is perfect – the differences are much less noticeable (i.e. the first comparing texture).

Questions and answers

1) S3TC has already become widely available, FXT1 was announced also long time ago. Why did we write this review then?

The answer is simple - so far I haven't seen a quality comparison of these two technologies. I tried to show you real highs and lows of the technologies. Not those which you could read in the issues from the companies themselves. Besides, it was necessary to carry out quality comparison of S3TC/FXT1 with 16-bit textures. I hope that I managed to make a clear report on weak and strong points.

2) Why do then we use compressed textures if they can be worse than 16-bit in terms of quality?

Answer: Remember that S3TC/FXT1 compressed textures take 3-4 times less space than 16-bit one. Besides, here (especially in visual comparison) I considered several textures which fit the compression very bad, like S3TC/FXT1. These textures are an exception, since the main ones such as walls, floor, ceiling and others look much better when compressed than 16-bit ones. But in general, games are to be provided with the textures which can be compressed, that is they should be in the definite format. One of such examples is light maps of low resolution. You can see it clearly in Quake 3 Arena with usage of compression.

3) Why have we taken FXT1 that is used nowhere today?

Answer: Nowadays we can't see any other widely available technologies except the prevalent S3TC. But we are to compare it with something, so we chose 3dfx as it's new and therefore it should be more advanced.

Conclusion

When using modern methods of texture compression we usually obtain better results than that of 16-bit textures, or at least the same, but at the same time it takes much less space in the video memory. The quality of S3TC compressed textures is comparable to that of 32-bit uncompressed textures, but for some especially unfavorable cases (textures of sky, light map etc.). In such cases it's necessary to restrain compression of such images or to allow a user to choose the texture format, let him choose between speed and quality. This approach was implemented in technological test of the game Serious Sam Test - there a user can choose the texture formats separately for walls/ceilings/floor, models of gamer/monster, light map etc. The choice is quite wide - 16-bit one with dithering (several degrees)/without it, 32-bit, S3TC.

S3TC technology appeared much earlier than its competitor, this is widely used by manufacturers of graphics chips. The technology provides very good quality of compressed images at the expense of their large size than that of competitor from 3dfx. As for the ratio "compression degree/quality", I think that this technology has it much superior among the present. It's supported already in DirectX (DXTC), and it is a huge advantage.

S3TC features:

• Decent quality - low banding
• Admissible compression degree
• Not bad speed of compression/decompression
• Perfect support from video chip manufacturers
• Good support from developers of games and applications
• Compulsory licensing by video chips manufacturers in case of usage the technology in OpenGL

FXT1 provides compassion with higher quality losses as compared with S3TC. This method allows to decrease texture size more. Until there is no more perfect technology, FXT1 allows to reach the best results as far as compression degree is concerned. Though in some cases the quality obtained looks unacceptable. Another weak point is compression speed. The main issue is: will we see some day FXT1 compression in real games? I think, no. S3TC is already widely available, that's why I don't see any reasons for developers to come to other rear and less quality compression methods (though they might have higher compression degree. Another goody is that FXT1 is open, though it hasn't helped it so far.

FXT1 features:

• Moderate quality - noticeable banding in the gradient textures and low detailing in the usual ones
• High compression degree
• Openness of the technology
• Low compression speed
• Bad support from video chip manufacturers
• Low support from developers

Now some words on the compression in general. It proved itself completely, with decreasing memory size you can get more detailed texture. The only thing that developers should do is to start wide usage of S3TC/DXTC texture compression, and compression technologies would get a vivid push for further development.

Finally, I'd like to mention what I want in further games/technologies: several compression coefficients (i.e. from 1:2 to 1:8) and therefore different quality. It would be better if a user could choose a method of compression himself for each texture type (basic, textures of models, sky, light maps, environment maps etc.). A possibility of separation of compression at texture size wouldn't be so bad either, for example, to restrict compression of textures of light which are less than 64X64.

Write a comment below. No registration needed!