S3TC (Texturenkomprimierung) in Q3A

13. März 2000 / von Leonidas

Der Rest der Menschheit beschäftigt sich zwar lieber mit dem Full-Scene-Antialiasing (FSAA) der 5.08er Detonatoren aber ich habe diesen Artikel der Texturenkomprimierung (S3TC) gewidmet. Im Gegensatz zum extrem leistungsfressenden FSAA ist S3TC ein Feature was auch real nutzbar ist.

S3TC können momentan nur die Savage2000-Karten von S3 (Diamond Viper II) und die GeForce-Karten von nVidia mit dem 5.08er Treiber. Die Qualitätsaussagen dieses Artikels treffen denke ich für alle Karten zu die S3TC können oder später mal können werden - die Leistungsaussagen natürlich nur für die 5.08er GeForce-Treiber.

Die Texturenkomprimierung in Quake 3 - Wie funktionierts?

In der ersten News zum Thema hatte ich leider fälschlicherweise behauptet das Quake 3 als komprimierte Texturen nur 16-Bit-Texturen nutzt. Richtig aber ist das Quake 3 beim Einladen des Levels die Texturen komprimiert und in komprimierter Form in den Speicher der Grafikkarte ablegt (während bei UT schon vorkomprimierte 16-Bit-Texturen auf der Extras-CD liegen). Dies funktioniert sobald Quake 3 eine Grafikkarte erkennt welche Texturenkompression anbietet. Das heißt mit den 3.76er Treibern funktioniert es nicht, sobald aber die 5.08er im System sind komprimiert Quake 3 die Texturen automatisch.

Das zugehörige Konsolenkommando r_ext_compress_textures steht bei Nutzung des 5.08er Treibers sofort auf "1" (wie "enabled"). Ausgeschaltet wird das ganze mit r_ext_compress_textures 0, um diese Änderung wirken zu lassen gefolgt vom Kommando vid_restart. Wieder einschalten mit r_ext_compress_textures 1 und danach vid_restart (anstatt des vid_restart kann man Quake 3 auch jeweils neustarten).

Wo liegt ganz ohne Komprimierung der Unterschied zwischen 16- und 32-Bit-Texturen?

Das Quake 3 auch 32-Bit-Texturen komprimiert ist sogar mir mittlerweile klar >:->. Frage: Ist das was nach der Komprimierung herauskommt auch wirklich noch 32 Bit?

Nun - um das zu klären mußte ich mich erst mal auf die Suche begeben nach dem Unterschied zwischen 16- und 32-Bit-Texturen in ganz normal unkomprimierter Umgebung. Was gar nicht so einfach war, ein an irgendeinen Punkt exakt festmachbarer Unterschied ist in normalen Maps nicht zu sehen. Was ich dann noch gefunden habe sind zwei äußerst zweideutige Screenshots (alle hier getätigten Screenshots sind 1024*768 mit 32 Bit Renderingtiefe auf ansonsten maximalsten visuellen Einstellungen ausgenommen die jeweilig verschiedene Texturenqualität, Map: Q3Tourney3):

Von der Sache ist wirklich kein Unterschied an den Gebäuden und sonstiger Umgebung zu sehen. Schwach ist jedoch am Himmel der Vorteil der 32-Bit-Textur sichtbar - die Übergänge sind feiner. Ich schätze aber ansonsten ist im normalen Spiel absolut kein Unterschied wahrnehmbar. Ich hatte jedenfalls in anderen Maps überhaupt keine Unterschiede sichten können, daß ausgerechnet in der Annihilator-Map Q3Tourney dies halbwegs sichtbar wird ist ernsthaft nur Zufall.

Ein echter festzumachender Unterschied kommt wo anders zutage: Man achte bitte auf die gelbe Munitionsanzeige links unten. Das läuft zwar nicht direkt unter "Textur", da aber Texturen auch nichts anderes als Bitmaps sind und diese Munitionsanzeige auch ein Bitmap ist, ist es technisch das gleiche. Bei der 16-Bit-Textur der Munitionsanzeige sind feine Abstufungen zu von oben nach unten zu erkennen welche bei der 32-Bit-Textur nicht mehr sichtbar sind. Diesen deutlichen Unterschied kann man in jedem normalen Spiel sehen - man braucht nur die Texturenqualität ändern.

Wenn man weiss wonach man suchen muss ist es einfach diese Unterscheidung 16- und 32-Bit-Textur zu sehen. Anderseits liegt hier die schon erwähnte Zweideutigkeit dieser Screenshots - es ist mir zwar möglich anhand einer nebensächlichen 2D-Textur den Unterschied zwischen 16- und 32-Bit-Texturen zu zeigen aber auf dem eigentlichen Screenshot ist - abgesehen vom Himmel - kein Unterschied zwischen der 16- und der 32-Bit-Textur.

So gesehen würde ich den Unterschied zwischen 16- und 32-Bit-Texturen nicht besonders einstufen - es sind wohl nur wenige Prozent Qualitätsunterschied (wenn man so etwas überhaupt in Zahlen ausdrücken kann).

Und nun mit Komprimierung?

Die Frage eins wäre ob es den bei den komprimierten Texturen auch wieder die beobachteten Unterschiede zwischen 16- und 32-Bit-Texturen gibt. Am Himmel ist es diesmal schlechter bis gar nicht zu sehen - die Munitionsanzeige gibt aber den eindeutigen Hinweis daß die Texturenkomprimierung durchaus einen Qualitätsunterschied zu zeigen vermag wenn sie 32-Bit-Rohmaterial in Arbeit hatte.

Der andere Punkt ist folgender: Für meine Begriffe sehen beide komprimierten Texturen verpixelter aus - rein gefühlsmäßig. Dazu kommt hinzu, daß der Himmel in komprimierter Form wirklich mies aussieht - hier stellt sich dann die Frage ob man die komprimierte 32-Bit-Textur von der Qualität her wirklich mit einer unkomprimierten 32-Bit-Textur gleichsetzen kann? Ich sehe hier eher die Qualität der komprimierten 32-Bit-Textur im Bereich der unkomprimierten 16-Bit-Textur!

Grundsätzlich gesehen ist das nur eine Feststellung. Ich will nicht an der technischen Möglichkeit der Texturenkomprimierung herummäkeln. Bei all dieser Euphorie ist aber der Hinweiss (und der obiger Beweis) das die S3-Texturenkomprimierung eben nicht verlustfrei arbeitet nicht unangebracht. Bezüglich der reinen Qualität bleibt das Verfahren von S3 jedenfalls ein zweischneidiges Schwert ...

Positive Nachrichten?

Ja! Die von verschiedenen WebSites berichteten Geschwindigkeitsvorteile durch den 5.08er-Treiber sind zwar im Normalfall auf das verbesserte T&L und nicht auf die Texturenkomprimierung zurückzuführen - aber es gibt auch Ausnahmen.

Jeder der das Annihilator-Timedemo mal unter 1024*768 @ 32 Bit, den höchsten Texturendetails und 32 Bit Texturenqualität mit einer Karte ohne Texturenkomprimierung und 32 MB oder weniger Grafikkarten-RAM laufen lassen hat wird mir hier problemlos folgen können. Da nutzt dann auch kein 800er Athlon etwas - mehr als 5 bis 6 Bilder pro Sekunde im Durchschnitt sind nicht möglich. Obwohl nicht unbedingt so beabsichtigt verwendet dieses Timedemo mit diesen Einstellungen schätzungsweise 25 MB Texturen - und das konstant in jeder Szene (wenn man davon spricht das eine bestimmte Map soundso große Texturen verwendet geht es im Normalfall um die Gesamtgröße der verwendeten Texturen in der kompletten Map - in jeder einzelnen Szene ist aber immer nur ein Bruchteil davon zu sehen).

Die Verwendung der Texturenkomprimierung läßt jedenfalls die Framerate unter den vorgenannten Einstellungen auf das vierfache explodieren - hinein in den spielbaren Bereich:

	unkomprimiert	komprimiert
Q3A, Annihilator-Timedemo, 1024*768 @ 32 Bit, beste visuelle Einstellungen	4,0 fps	15,9 fps

Was sich mir angesichts dieser Resultate sofort als Schlußfolgerung aufdrängt:
Eine 64-MB-GeForce wird damit absolut unnötig. Denn nur für einige Quake3-Maps lohnte sich diese Karte, mit der Texturenkomprimierung erledigt sich das aber ganz schnell. Nachtrag.

Schlußwort

Besonders mit diesen Benchmarks vor Augen - immer her mit der Texturenkomprimierung!
Immerhin bekommt man sozusagen eine Grafikkarten-RAM-Aufrüstung ganz kostenlos. Und so gesehen ist damit auch der Verlust der echten 32-Bit-Qualität durch die Komprimierung der Texturen verschmerzbar.

Nicht vergessen werden sollte allerdings das der große Kick für die GeForce erst dann kommen wird, wenn die Texturenkomprimierung in Unreal Tournament möglich wird und damit die Nutzung der hochauflösenden vorkomprimierten Texturen auf der UT-Extras-CD.

Nachtrag vom 14. März ...

Das ging dann aber ein bißchen zu fix! Warum kann die Texturenkomprimierung so einfach eine 64-MB-GeForce ersetzen? Das hängt an der Frage wann diese 64-MB-GeForce schneller ist als eine mit 32 MB. Im Prinzip nur in Quake 3 und dort ausschließlich bei der Verwendung von 32 Bit Texturen und der höchsten Texturenqualität. Dies ist nicht mit demo001 oder demo002 feststellbar sondern ausschließlich mit Demos welche Maps mit sehr großen Texturenaufkommen benutzen, wie das Quaver- oder das Annihilator-Demo.

Denn ausschließlich dann wenn es im RAM der Grafikkarte eng wird (weil zu stark gefüllt mit Bilddaten und Texturen wie in vorgenannten Quake3-Demos) werden sich die zusätzlichen 32 MB RAM in einen Vorteil sprich mehr Geschwindigkeit ummüntzen lassen. Wenn die 32-MB-Grafikkarte in irgendeiner Anwendung nicht ausgelastet ist, das heißt der Speicher nicht komplett belegt ist, kann die 64-MB-Grafikkarte - vor die gleiche Aufgabe gestellt - nicht schneller sein! Das Problem des extremen RAM-Bedarfs einiger Quake3-Maps ist aber mittels der Texturenkomprimierung lösbar (siehe obige Benchmarks) - ansonsten hat die 64-MB-GeForce keine weiteren Vorteile zu bieten.

In keinem anderen Spiel außer Quake 3 (in den vorgenannten extrem hochwertigen visuellen Einstellungen) ist derzeit ein Vorsprung der 64-MB-GeForce feststellbar. Zudem gebe ich persönlich nicht viel auf die Parole von der besonderen Zukunftsfähigkeit einer solchen Lösung - die Welt ist jetzt und heute, alles andere ist Schnee von morgen. Insofern kann eine GeForce mit "nur" 32 MB RAM die 64-MB-GeForce-Karten komplett ersetzen, mittels Texturenkomprimierung wird es keinerlei Leistungsunterschiede geben.

zurück zum entsprechenden News-Beitrag