DirectX - von den Anfängen bis zur Gegenwart (III)

Nach der Integration der ersten Shader-Funktionen in DirectX 8 setzte Microsoft konsequent nach: DirectX 9 bohrte die Fähigkeiten deutlich auf, unterstützte Gleitkomma-genaue Formate für Farb-Puffer, Texturen und Render Targets. Den größten Schritt aber machte Microsoft wahrscheinlich mit dem umfangreichen Toolkit, welches die DirectX-Version 9 begleitete. In dieser Hinsicht konnte sich DirectX schon immer von der alternativen Schnittstelle OpenGL absetzen, die dem Entwickler mehr Freiheiten, aber auch mehr Eigenleistung einräumte.

DirectX 9 sah auf der Hardwareseite aber auch die bis dato größte Fehlleistung Nvidias, welche mit der Geforce FX nicht nur wesentlich später als Ati mit der Radeon 9700 antraten, sondern performanceseitig auch so stark hinterher hinkten, dass in DX9-Titeln sogar das Mittelklasse-Modell der Radeon, die 9600 XT, oft schneller als Nvidias schnellste Lösung jener Zeit war. Die FX 5800 Ultra erlangte wegen ihrer übertrieben hohen Taktfrequenzen und der daraus resultierenden, hohen Leistungsaufnahme auch den traurigen Beinamen "Der Fön" in Anlehnung an das Geräusch ihres Radiallüfters.


Lesezeichen: DirectX-Reihe
• DirectX - von den Anfängen bis zur Gegenwart (I)
• DirectX - von den Anfängen bis zur Gegenwart (II)
• DirectX - von den Anfängen bis zur Gegenwart (III)

Einen Blick wert sind auch die Bildergalerien der Techdemos von Ati/AMD und Nvidia, die alle wichtigen Veröffentlichtungen seit der DirectX-8-Zeit umfassen.


Hinweis: Der folgende Artikel erschien im Original in der PC Games Hardware 04/2002 und wurde lediglich hinsichtlich der Formatierung an das Online-Angebot angepasst und um einige Bilder erweitert, Autoren: Raphael Auf der Maur & Thilo Bayer

3D der nächsten Generation
DirectX 8.1 und OpenGL 1.3 sind neu am Markt, doch die Software-Ingenieure werkeln bereits an Weiterentwicklungen. Was bringen DirectX 9 und OpenGL 2.0?

Noch spricht man allgemein von den Vorzügen der Beschleuniger der DirectX-8-Generation. Doch mit dem für den Spätsommer geplanten DirectX 9 wird bereits die nächste Evolutionsstufe eingeläutet. Auch die eher behäbige Entwicklung des plattformübergreifenden Gegenstücks OpenGL kommt wieder in Fahrt. Welche Technikschmankerl sind zu erwarten und wie soll damit die Optik künftiger Spiele verbessert werden? Wir erklären bereits heute, was Sie im heißen 3D-Herbst zu erwarten haben. Denn unser Blick auf die brandneuen Technikdokumentationen enthüllt auch die noch geheimen Features der nächsten Beschleunigergeneration.

DirectX 8 mit Konzeptschwächen
Microsoft gibt klar den Takt an, wenn es um die Integration moderner 3D-Features in deren Direct3D-Programmierumgebung geht. Dass bei dem forschen Tempo auch manchmal die grundsätzlichen Konzepte einer Programmierschnittstelle vernachlässigt werden, ist die Kehrseite der Medaille. So bemängeln Experten die noch eingeschränkte und verwirrende Struktur des DirectX-8-Shader-Konzepts. Bei der Entwicklung der Pixel-Shader-Sprache für DirectX 8 ließ sich Microsoft zu stark von rivalisierenden Chipentwicklern beeinflussen. So fanden fünf verschiedene und zum Teil zueinander inkompatible Shader-Standards den Weg in das DirectX-8-Menü (Version 1.0 bis 1.4). Jede Version ist dabei auf die Fähigkeiten einer bestimmten Chiparchitektur (3dfx, Geforce3, Geforce4 Ti bzw. Radeon 8500) zugeschnitten, von einem einheitlichen Konzept fehlt jede Spur. Diesen Lapsus haben die Microsoft-Ingenieure erkannt und geloben Besserung für die Version 9 des Programmierpakets.

Pixel Shader werden ausgebaut
Die aktuelle Pixel-Shader-Version 1.4 wird dabei als Grundlage genommen und zur Version 2.0 weiterentwickelt. In DirectX 9 werden außerdem bis zu acht Texturen (bisher sechs) die Berechnungen eines Pixels beeinflussen können. Die Anzahl der zur Verfügung stehenden Maschineninstruktionen ("Assembler-Befehle") wird ebenfalls erweitert, in DirectX 9 werden 64 mathematische Rechenbefehle und 32 Befehle zum Lesen von Texturdaten zur Verfügung stehen. Ergänzt wird die Programmierbarkeit um Funktionen zur Nebel-Erzeugung. Bisher standen dafür nur fest vorgegebene Funktionen zur Wahl. Eher sanften Änderungen ist die programmierbare T&L-Einheit ("Vertex Shader") unterworfen. In DirectX 9 werden die Programme zur Eckpunktberechnung auch Schleifen beinhalten können, was die Programmierung erleichtern dürfte. Auch die Anzahl der Zugriffsmöglichkeiten auf chipinterne Speicherplätze ("Register") wird erhöht, von 128 auf 256, ebenso die maximale Länge eines Programms.

Vielleicht bereits werden bei DirectX 9 die neuen Shader-Standards von einer übergeordneten "High-Level"-Programmiersprache flankiert. Dabei steht nicht mehr der direkte Zugriff auf die Hardwarebefehle und Speicherplätze im Vordergrund, sondern ein abstrahiertes Programmiermodell, in dem die Programmierer losgelöst von Hardwareeigenheiten ihre Effekte verwirklichen können. Statt auf kryptische Assembler-Befehle sollen die Entwickler auf gewohnte "C-typische" Anweisungen zurückgreifen, Befehle, die auch beim Programmieren der anderen Teile des Spiels genutzt werden. Spezialeffekte sollten sich dadurch einfacher und schneller entwickeln lassen. Die Erleichterungen dürften auch weniger geübte Spieleprogrammierer dazu verleiten, knifflige Shader-Effekte einzusetzen. Ein vom jeweiligen Chiphersteller zur Verfügung gestelltes Spezialprogramm ("Compiler") bzw. der Grafikkartentreiber sorgt dafür, dass die "Shader"-Progrämmchen korrekt in die Maschinensprache umgewandelt werden. Ob diese "Hochsprache" jedoch im vollen Umfang in DirectX 9 zu finden sein wird, steht noch nicht endgültig fest. Die Vereinheitlichung der Kommandos für Pixel- und Vertex Shader ist zumindest erst für DirectX 10 eingeplant.

Gesetzt ist jedoch eine neue und speziell für dreidimensionale Texturen geeignete Kompressionstechnologie. Bisher werden 3D-Texturen lediglich mit einer angepassten Form des S3TC-Algorithmus komprimiert, der eigentlich für zweidimensionale Texturen entwickelt wurde. Mit der von Nvidia entwickelten VTC ("Volume Texture Compression") sollten 3D-Texturen besser komprimiert werden können und endlich praktisch nutzbar werden. 3D-Texturen eignen sich in Spielen unter anderem für ausgefeilte Lichteffekte.

Displacement Mapping
Bisher unbekanntes Terrain betritt Microsoft mit der Integration von Displacement Mapping ("Verschiebungs-Mapping"). Zwei verschiedene Methoden sollen dabei integriert werden, eine Methode für Objekt- und eine für Geländeveränderungen. Verschiebungswerte geben an, wie stark sich ein Punkt an einer bestimmten Stelle verschieben soll. So lassen sich glatte Oberflächen (beispielsweise auch Freiformflächen) nachträglich mit Furchen und Wölbungen versehen. Die erzeugten Effekte sind ähnlich wie bei "Bump Mapping". Die Farbwerte einer "Bump Map" variieren jedoch nur die Beleuchtung der Pixel, um durch die geänderte Schattierung eine Wölbung vorzutäuschen. Mittels Displacement Mapping wird die Wölbung "physisch" angewandt und ist daher auch an den Umrissen einer Figur sichtbar, das Objekt verändert seine virtuelle Gestalt. Dadurch kann es Schatten auf sich selbst werfen ("Self-Shadowing"), was mit Bump Mapping unmöglich ist.

Die Displacement Mapping-Methode für Objekte klinkt sich in die Vertex-Shader-Einheit ein und variiert die Eckpunktpositionen. Wenig kooperativ zeigt sich diese Methode mit dynamischen Level of Detail-Modellen (siehe PCGH 2/02) und dynamischer Flächenzerlegung ("Adaptive Tesselation"), punktet dafür bei der Geschwindigkeit.

Die Methode für Geländeveränderungen arbeitet mit speziellen Verschiebungstexturen in Kombination mit N-Patches ("Truform"). Die Oberfläche wird erst beim Rendering der stark zerlegten Ur-Dreiecke verändert, die Verschiebungsdaten werden aus einer speziellen Textur gelesen. In Echtzeit erzeugtes Displacement Mapping sorgt für wabernde Oberflächen (Wasser) und Deformationen an bestehenden Geometriemodellen (beispielsweise Fahrzeugschäden nach einer Kollision). Interessant ist Displacement Mapping jedoch vor allem in Zusammenarbeit mit Freiformflächen ("Curved Surfaces"). Selbst komplizierte und sehr detaillierte Geometriemodelle lassen sich auf diese Weise sehr platzsparend über den ohnehin schon stark belasteten AGP-Bus übertragen. Geländestrukturen erscheinen nach der Veränderung durch eine Displacement Map realistisch zerklüftet und natürlich rau.

Mehr Präzision
Als wichtige Neuerung in DirectX 9 gilt die Unterstützung von höherer Farbgenauigkeit bei der Pixelberechnung. Dabei gilt es, zwischen interner und externer Rechengenauigkeit zu unterscheiden. Die externe Farbgenauigkeit wird vom Spieler beim Start des Spiels oder in den Spieleoptionen festgelegt und beträgt in der Regel 16 oder 32 Bit. Damit wird festgelegt, mit welcher Genauigkeit die Farbwerte im Grafikkartenspeicher endgelagert werden. Anders die interne Rechengenauigkeit. Diese beträgt bei allen aktuellen Grafikchips immer mindestens 32 Bit, unabhängig von den Einstellungen im Spiel.

Die interne Rechengenauigkeit ist bei Multitexturing- und Pixel-Shader-Effekten maßgebend. Je höher die interne Genauigkeit, umso weniger Rundungsfehler entstehen bei der Kombination mehrerer Texturschichten und bei mathematischer Kombinierungsfunktionen, die innerhalb des Chips ablaufen. Außerdem ermöglicht eine höhere interne Genauigkeit bessere Beleuchtungseffekte.

Nicht nur für's Auge
Bei einer internen Rechengenauigkeit von 32 Bit stehen je 8 Bit für die Zwischenspeicherung der Rot-, Grün-, Blau- [R, G, B] und Transparenzanteile eines Pixels zur Verfügung. Mit 8 Bit lassen sich für jeden dieser "Kanäle" 256 Zustände speichern, für die drei Grundfarben lassen sich derzeit also 256 verschiedene Abstufungen realisieren. Die 256 Abstufungen werden auf einen Bereich von 0 bis 1 herunterskaliert. Die Farbe schwarz wird dann mit [R=0, G=0, B=0] dargestellt, weiß erhält den Wert [1,1,1].

Im ersten Moment reicht diese Genauigkeit aus, um unser Auge mit einer ausreichenden Anzahl Farben zu verwöhnen. Problematisch wird der begrenzte Rechenraum jedoch, sobald die Farbwerte in Berechnungen einfließen. Folgendes Rechenbeispiel verdeutlicht dies. Der Farbwert einer Textur soll zu einem im vorherigen Rechenschritt berechneten hellorangen Farbwert hinzuaddiert werden. Das helle Orange hat dabei RGB-Anteile von 1, 0.5 und 0.125. Der gelesene Texturwert stellt eine hellgrüne Farbe dar, welche die Anteile [0.25, 1, 0.25] aufweist. Die Addition dieser beiden Farben ergibt einen neuen Farbwert mit den Anteilen [1.25, 1.5, 0.375] für Rot, Grün bzw. Blau. In einem nächsten Schritt soll dieser Farbwert mit einer Beleuchtungstextur (Lightmap) multipliziert werden. Beleuchtungstexturen dunkeln die Pixel ab, so wird das eben berechnete Pixel an dieser Stelle beispielsweise mit einem Wert von 0.50390625 multipliziert. Der endgültig berechnete Farbwert beträgt [0.6298828125, 0.755859375, 0.18896484375].

Hier zeigen sich zwei Probleme. Mit 8 bits lassen sich diese Werte nicht genau abspeichern. Es muss auf die nächstmöglichen Werte gerundet werden, in diesem Fall [0.62890625, 0.7578125, 0.1875]. Im Zusammenhang mit Pixel Shader können solche Rundungsfehler schwer wiegende Folgen haben und sich im Verlaufe der Berechnung zu sichtbaren Farbverfälschungen aufschaukeln. Weiteres Problem: Mit 32 Bit lässt sich das erste Zwischenresultat gar nicht abspeichern, die Werte sind auf maximal 1.0 beschränkt. Ein mit nur 32 Bit rechnender Grafikchip begrenzt das Zwischenresultat aus der Addition von Hell-Orange und Hell-Grün Werte auf [1, 1, 0.375]. Das Endresultat in heutigen Grafikchips beträgt deshalb fälschlicherweise [0.50390625, 0.50390625, 0.1875]. Statt eines matten Grün berechnen unsere heutigen Grafikchips fälschlicherweise ein dunkles Beige.



Reale Berechnungen mögen von dem hier gezeigten einfachen Beispiel abweichen, doch die Grundproblematik bleibt dieselbe. Bei dem heute zur Verfügung stehenden Farbbereich stoßen die Entwickler bei der Entfaltung ihrer Shader-Kreativität an Grenzen. Bereits vor Jahresfrist verlangten prominente Spieleentwickler wie John Carmack (id software) nach höherer Rechengenauigkeit für ihre künftigen Spiele-Projekte.