Wie stark komprimiert 3Dc?

15. Juni 2005 / von aths / Seite 7 von 7

   3Dc-Dekodierung

Wir haben noch nicht gesagt, wie denn nun die Dekomprimierung von 3Dc funktioniert. Zunächst einige Worte zum Alpha-Kanal für DXTC. Mit DXT1 kann man wie bereits besprochen entweder 4 Farben speichern (davon zwei interpoliert) oder, das sollte nicht unerwähnt bleiben, drei Farben (davon eine interpoliert) sowie die Information "voll durchsichtig". Diese Entscheidung kann übrigens pro einzelnem DXT1-Block neu getroffen werden.

Für feiner abgestufte Transparenz gibt es DXT3 und DXT5. Diese Formate speichern zunächst die Farbe wie gewohnt mittels DXT1 mit zwei interpolierten Farben. Außerdem wird ein neuer Block für die Alphawerte angehängt. Dieser ist dann noch einmal 64 Bit groß. Bei DXT3 werden 16 Werte à 4 Bit gespeichert. 0000 steht für "völlig durchsichtig", 1111 für "völlig opaque". 0011 steht für "20 Prozent sichtbar" – man hat also den Bereich von 0 bis 100 Prozent Sichtbarkeit in 16 Schritten aufgelöst zur Verfügung.

Der Alpha-Teil von DXT5 ist anders aufgebaut: Zunächst werden zwei Alpha-Werte mit je 8 Bit gespeichert. Dann folgt pro Texel ein 3-Bit-Wert. 000 steht für "voll Alpha-Wert_1", 111 für "voll Alpha-Wert_2", und für die sechs Bitkombinationen zwischen 001 bis 110 werden die beiden Referenz-Alphawerte linear interpoliert. In einem alternativen Modus werden nur vier Alpha-Werte interpoliert, damit in jedem Fall die beiden Ausnahmen "voll transparent" und "voll sichtbar" gespeichert werden können. Diese Entscheidung kann man pro einzelnem DXT5-Block neu treffen.

DXT2 entspricht vom Aufbau her genau DXT3, nur dass die Farbwerte als bereit mit dem Alphawert multipliziert gelten. Der gleiche Zusammenhang besteht zwischen DXT4 und DXT5, heutzutage finden DXT2 und 4 praktisch keine Anwendung mehr.

3Dc speichert die beiden Komponenten für die Zweikanal-Normalmap jeweils genau so wie Alpha bei DXT5 gespeichert wird. Die Hardware braucht also zwei Dekodier-Einheiten für den DXT5-Alphateil und unterstützt dann 3Dc. Das heißt, wirklich neu ist ATIs Idee mit 3Dc nicht. Wenn man DXT für Normalmap-Komprimierung "missbraucht", nutzt man gerne eine Variante mit Alpha-Teil, konkret DXT5, da Alpha unabhängig von den Farbkomponenten gespeichert ist. ATI kam nun auf die Idee, zwei unabhängige DXT5-Alpha-Blöcke zusammenzupacken und das 3Dc zu nennen.

Wie im Kapitel zu DXTC schon erwähnt, ist die Komprimierung von Farbwerten mit DXT recht aufwändig. Denn man speichert zwei komplette RGB-Vektoren, während bei 3Dc die einzelnen Komponenten des XY-Vektors unabhängig sind. Damit lassen sich sehr einfach brauchbare Referenzwerte bestimmen, nämlich in erster Näherung jeweils das Minimum und das Maximum. Es geht auch besser, was aber weiterhin viel einfacher bleibt, als wenn man mit DXTC gute Bilder-Komprimierung erreichen möchte. Die Komprimierung zu 3Dc ist jedenfalls recht simpel, was natürlich ein Vorteil ist.

   Ausblick

Wird es bei dieser 2:1-Komprimierung bleiben? Wir halten den Komprimierungsfaktor für Normalmaps nicht mehr steigerbar, wenn man nicht noch mehr Qualität opfern möchte. Aber normales Bumpmapping ist nicht das Ende der Entwicklung. Betrachten wir noch einmal unser Höhenprofil.

Beim herkömmlichen Bumpmapping bleibt die Textur flach.

Die Textur liegt auf der grau eingezeichneten Polygonoberfläche, bleibt also völlig flach. Das Bumpmapping täuscht den 3D-Effekt alleine mittels Erhellung oder Abdunklung der Texturfarben vor. Eigentlich müsste die Textur ja auf dem Hohenprofil liegen. Mittels Offsetmapping (alternative Bezeichnungen: Parallaxmapping oder Virtual Displacementmapping) wird versucht, dem Rechnung zu tragen.

Mittels einer Demo von Humus (Download) haben wir das getestet. Unser Screenshot-Ausschnitt kann per MouseOver-Effekt zwischen Bumpmapping ohne und mit Offsetmapping angezeigt werden (MouseOver-Effekt per Javascript, Alternativ-Variante: Klick öffnet beide Screenshots):

Für das Offset-Mapping gibt es mehrere Ansätze, wobei die Erzeugung durchweg guter Qualität (also auch bei schwierigen Winkeln) leider sehr rechenaufwändig ist. Für solches Bumpmapping braucht man in jedem Fall auch noch die Heightmap. Wie wir vorhin beschrieben haben, kann eine Normalmap aus der Heightmap generiert werden. Da liegt der Gedanke nahe, nur die Heightmap zu speichern und die Normalmap "on the fly" zu generieren. Damit das entsprechend schnell geht, sollte das aber gleich im Texturfilter mit dedizierten Einheiten unterstützt werden. Das ist nicht ganz unproblematisch, könnte aber eines Tages kommen. Aus 8 Bit 32 Bit zu machen, entspräche mit etwas Fantasie einer 4:1-Dekomprimierung.

Tatsächlich sollte man aber nicht von einer Komprimierung sprechen, nur weil die Normalen on the fly aus der Heightmap erzeugt werden, sondern einfach von einer geringeren Bitrate. Ob die 8-Bit-Heightmap für ein vernünftiges optisches Ergebnis ausreicht, ist nicht ohne weiteres zu beurteilen. Wir meinen, für Allerwelts-Bumpmapping sollte dies noch gut genug sein.

Für solche Heightmaps könnte man sich dann noch eine spezielle Texturkomprimierung ausdenken – oder der Einfachheit wegen etwas schon existierendes nehmen: Die Alpha-Komprimierung vom DXT5-Verfahren, zum Beispiel. Dann wäre man bei 4 Bit pro Pixel, also der halben Datenrate von 3Dc, aber könnte nicht nur normales Bumpmapping, sondern zusätzlich Offset-Mapping applizieren.

   Fazit

Obwohl es keine geistige Schöpfung einer besonderen Höhe ist, da hierfür praktisch nichts neu entwickelt wurde, begrüßen wir die Möglichkeit, mit 3Dc bei gleicher Bitrate wie mit DXT5 insgesamt etwas bessere Qualität für Normalmaps anzubieten. In bestimmten Situationen kann DXT5 auch mal besser sein, dann hat man immerhin noch die Auswahl.

Was wir nicht begrüßen, ist ein Marketing, das von 4:1-Komprimierung spricht, wenn 2:1-Komprimierung geboten wird (aus 8 Bit pro Datum werden unter Inkaufnahme kleiner Verluste 4 Bit pro Datum) – und ein Marketing, welches das 3Dc-Format mit Z-Rekonstruktion vergleicht mit DXT5 ohne Renormalisierung.

Danksagung: Der Autor bedankt sich für Demirugs Aufmerksamkeit zum Thema 3Dc und für Franks Unterstützung bei der Mathematik; Dank geht auch an Xmas für allgemeine Hintergründe zum Thema Normalmapping und Rechnungen mit Normalen; last but not least geht eine Danksagung an zeckensack für seine präzisierenden Hinweise und an RLZ für seine Kritik bezüglich einiger Bilder.