Matrox Parhelia Preview

14. Mai 2002 / von aths / Seite 4 von 7

   VertexShader

Kommen wir zur programmierbaren T&L-Einheit, sprich dem Vertex Shader: Dort gibt es eine Menge Neuerungen. Der VertexShader des Parhelia ist Vertex Shader 2.0 konform und erfüllt in diesem Punkt die DirectX9-Anforderungen. Das bedeutet zum Beispiel, dass 256 statt bisher nur 96 Konstanten gespeichert werden können. Konstanten-Arrays werden oft als Look-Up-Tabelle genommen - das ist notwendig, um beispielsweise mathematische Funktionen annähern zu können. Je mehr Konstanten möglich sind, desto genauer können dann die Ergebnisse werden. Außerdem wurde die Programmlänge von 128 Befehle auf 512 erweitert.

Ob man das braucht, hängt natürlich wieder vom darzustellendem Effekt ab. Damit die Transformation flexibel ist (sprich, die CPU nicht ständig eine neue Transformations-Matrix berechnen muss), wurde sie in DirectX8 programmierbar gestaltet. Längere Programme ermöglichen Effekte, die mehr Einflussgrößen berücksichtigen. Natürlich steigt auch die Berechnungszeit in der Grafikkarte an. Die intern vierfache Auslegung des Vertex Shaders (GeForce3, Radeon 8500: 1fach, GeForce4 Ti: 2fach) ist also nicht übertrieben, wenn längere Programme genutzt werden. Dazu ein nettes Beispiel-Bild von Matrox:

Bei diesem Bild kamen auch der PixelShader zum Einsatz und es wurde 16x Anti-Aliasing verwendet. Es wurden für den VertexShader 2.0 natürlich auch neue Befehle definiert. So sind nun Iterationen (ähnlich dem Schema einer FOR-Schleife) möglich. Ebenso dürfen endlich Sprung-Befehle verwendet werden, allerdings kann man mit diesen Befehle nur in Programmablauf-Richtung überspringen (Rücksprünge gibt es also nicht).

   Displacement Mapping

Kommen wir nun zum Glanzstück: Eines der hervorstechendsten Merkmale des Matrox Parhelia ist der Hardware-Support von Displacement Mapping. Zunächst ein paar Beispiel-Bilder:

Wir sehen einen Würfel. Er besteht aus nur 12 Dreiecken und 6 Displacement Maps. Intern findet eine Umrechnung in viele tausende Dreiecke statt.

Ausgehend vom gleichen (und recht groben) Grundmodell lassen sich mit unterschiedlichen Displacement Maps ziemlich verschiedene Charaktere erzeugen.

Dieses Modell wurde mit einer Displacement Map verzerrt.

Der vielleicht größte Vorteil hierbei ist die sogenannte "Depth-Adaptive Tesselation". Das heisst, dass automatisch eine geometrische Detail-Anpassung stattfindet. Bislang musste dies grundsätzlich von der CPU gemacht werden. Und dies ist bekanntlich die Crux: Je besser die geometrische Detail-Anpassung (adaptives LOD), desto mehr hat die CPU zu tun. Was sie an Transformations-Aufwand spart, geht dann in die LOD-Anpassung.

Matrox´ Lösung ist also deswegen zu begrüßen, weil die CPU genauso wie die GPU erheblich entlastet wird - jedenfalls, wenn man Displacement Mapping verwendet. Eine Displacement Map ist dabei nichts weiter als eine "Karte", welche die Höhe angibt. Die Displacement Maps (DM) sind intern nur Texturen. Im Gegensatz zu Bump Maps ist MIP-Mapping mit Displacement Mapping kein Problem. Über MIP-Mapping wird auch die adaptive LOD-Anpassung realisiert. Das läuft letztlich darauf hinaus, dass die sichtbaren Dreiecksgrößen auf dem Monitor alle ungefähr gleich groß sind. Ohne LOD würden die Dreiecke im Vordergrund deutlich größer sein, während sie im Hintergrund ineffizient klein wären.

Und: Während Bump-Mapping nur eine Illusion der Tiefe vermittelt, erzeugt Displacement Mapping echte veränderte Geometrie. Eindrucksvoll lässt sich dieser Effekt auf einer Kugel betrachten, wir zeigen hier ein schönes (inzwischen allerdings längst bekanntes) Bild:

Lassen wir zudem noch ein Spiel-Beispiel sprechen: Comanche 4 verwendet im Gegensatz zu seinen Vorgängern herkömmliche Polygon-Grafik, um Landschaften darzustellen. Die "VoxelSpace" genannte Grafik vom originalen Comanche1 nutzt entgegen dem Begriff keine Voxel, aber in gewissem Sinne Displacement Maps. Der Parhelia ist nun der erste Grafikchip, welcher dieses Uralt-Spiel in Hardware beschleunigen könnte. Die Prinzipien, wie die Landschaft nun genau gerendert wird, unterscheiden sich bei Comanche1 und Displacement Mapping zwar, das Resultat wäre aber sehr ähnlich. Displacement Mapping führt - im Gegensatz zur "VoxelSpace-Engine" - die Landschaft wieder auf Polygongrafik zurück, ist dafür aber auch weitaus flexibler einsatzbar, als für Landschaften á la Commance1 erforderlich.

Logischerweise sähe Displacement Mapping beschleunigtes 3D-Gelände deutlich besser aus, als wenn eine Software-Engine zum Einsatz kommt. Für kleine Details ist Bump Mapping dank geringerer Anforderungen nach wie vor das bessere Verfahren, für gröbere Details jedoch, bis hin zu Darstellung von Bergmassiven oder Schluchten, ist dann Displacement Mapping geeignet. Natürlich muss eine Engine extra für Displacement Mapping geschrieben werden, aber es gäbe kaum einen anderen vernünftigen Weg, dem Spieler ähnlich detaillierte Landschaften bei vergleichbarer Rechenlast zu bieten.