High(er Order Surfaces in DirectX 8.1 - Rettung oder Chaos?

Warum High Order Surfaces - Dreiecke reichen doch?

Bis Quake 3 auf dem Markt erschien wurden alle 3D-Level aus 1,2,3...x eckigen Polygonen zusammengesetzt. Meistens also Punkte, Linien, Dreiecke und Vierecke. Flächen die mehr als 4 Ecken besaßen, wurden aus Dreiecken zusammengesetzt, das hatte mathematische Gründe, da viele Berechnungen mit einem Dreieck am einfachsten sind - sie sind immer convex.



3D-Objekte werden aus vielen kleinen Dreiecken zusammengesetzt, denn je feiner ein Objekt in Dreiecke unterteilt ist, desto besser werden Rundungen und Bögen auch als solche erkannt. Mehr Dreiecke bedeutet auch mehr Arbeit für die CPU, da diese ja die Eckpunkte transformieren muss (Objekt-Koordinatensystem -> Welt-Koordinatensystem -> Kamera-Koordinatensystem -> Bildschirm-Koordinatensystem. Leider hat die CPU auch noch andere Dinge (KI, Kollisionsabfrage, Soundausgabe, Netzwerkcode, ... zu erledigen, deshalb sollte man die Anzahl der Dreiecke nicht zu hoch ansetzen, da sonst die Framerate unter 25 Bilder pro Sekunde fällt, was zu ruckelndem Spielablauf führt.



Als NVIDIA mit ihrem Geforce 256 hardwarebeschleunigtes T&L ( Transformation & Beleuchtung einführen, war die Euphorie groß. Endlich konnte man hochdetailliert Polygonobjekte verwenden, den von nun an wurde die gesamte Transformationsarbeit vom Grafikchip (GPU erledigt. Nebenbei erledigte er auch noch die Belechtung, die somit zwar nicht viel schneller wurde (keine parallele Berechnung mehrere Lichtquellen, aber wenigstens genauer. Somit hätte es nur eine kurze Zeitspanne dauern müssen, bis die T&L Einheit richtig ausgenutzt worden wäre und es genug Spiele auf dem Markt gäbe, die mit Polygonen nur so protzen.
Ganz so einfach, wie NVIDIA's Marketingabteilung uns das machen wollte, ist es leider nicht.
Hierzu einen kleine Rechnung:

Maximale Leistung, verschiedener GPU's (Herstellerangaben:

Geforce 256 - 15 Mio / Dreiecke (120 Mhz
Geforce 2 GTS - 25 Mio / Dreiecke (200 Mhz
Geforce 2 ULTRA - 31 Mio / Dreiecke (250 Mhz
Geforce 3 - keine offiziellen Angaben, weder auf der Homepage, noch in PDF's (2x-5x Leistung der Geforce 2 - ca. 50 Mio / Dreiecke!!! (200 Mhz
Radeon 30 Mio / Dreiecke (183 Mhz
Radeon 8500 75 Mio / Dreiecke (250 Mhz

Testsystem: Duron 1000(7,5*133, Geforce 2 Pro 4xAGP - DirectX 8 SDK - Optimized Mesh Demo (46464 Dreiecke aus 23232 Vertices pro Objekt, 16 solcher Objekte
Die Berechnungen erfolgten mit einer Lichtquelle, ein Vertex bestand aus X,Y,Z, Normalenverktoren und Texturekoordinaten, also 32 Bytes.



Da die Geforce 256 T&L Einheit genau die gleiche wie beim Geforce 2 GTS ist, habe ich die Geforce PRO auch mal mit 120 Mhz betrieben. Irgendwie sieht mir das nicht nach den versprochenen Werten aus. Bei 120 Mhz, also Geforce 256 Niveau kommt die GPU gerade auf 5 Mio. Dreiecke - versprochen waren aber 15 Mio! Bei der Geforce 2 GTS genauso, 8,3 Mio, versprochen waren 25 Mio. Haben wir da irgendetwas übersehen?
JA!
Nicht nur wir, sondern auch viele Entwickler von Spielen machten/machen diesen Fehler!
Es wurde ganz einfach vergessen, die Dreiecke in Cache freundlicher Reihenfolge an den GPU zu übergeben.

Vertex Cache (ein Vertex im Cache spart prefetch (holen und T&L Zyklen!:

Geforce 256 - 16 Einträge
Geforce 2 GTS - 16 Einträge
Geforce 3 - 24 Einträge
Radeon 30 Mio - Hersteller konnte keine Angaben machen
Radeon 8500 75 - Hersteller konnte keine Angaben machen

Es ist deutlich zu erkennen, dass die T&L Werte jetzt schon eher an die Herstellerangaben heranreichen. Zur Sicherheit, habe ich die Anzahl der Lichtquellen mal erhöht, allerdings nur bei 200 Mhz GPU Takt. Das Ergebnis:



Wie sich der Geforce 3, die Radeon und die Radeon 8500 hier verhält konnte ich leider nicht testen. Wenn jemand ein Testexemplar übrig hat, einfach ne Mail an mich. Mit 0 Lichtquellen steigt der Durchsatz kaum noch an, deshalb wurde es hier nicht mit aufgeführt.
Das Lichtquellenproblem ist aber recht einfach zu umgehen, einfach nur eine oder zwei verwenden. Dieses Beleuchtungsmodell hat sowieso an Bedeutung verloren, da heute und in Zukunft die Beleuchtung mit den Pixel Shadern erledigt wird.
Eine effiziente Anordnung und Vermeidung von Eckpunkten erreicht durch Fans und Strips.



In unseren Benchmarks haben wir ein Modell mit 46464 Dreiecken und 23232 Vertices verwendet. Dieses Mesh-Objekt ist optimiert, da auf jedes Dreieck, statistisch gesehen, gerade einmal 0.5 Eckpunkte kommen. Ohne Optimierung wären es 3 Eckpunkte pro Dreieck.



Bei 32 Byte pro Eckpunkt und 27,7 Mio. Dreiecken (3*27,7 Eckpunkte käme man so auf 2659,2 MBytes (2,7 GB pro Sekunde.

1. Flaschenhals

Der RAM - außer RDRAM mit zwei, oder mehr Kanälen schafft kein anderer RAM diese Bandbreiten.

2. Flaschenhals

Der BUS - selbst AGP 8x würde nur etwas mehr als 2000 MBytes befördern und Texturedaten benötigen auch noch Bandbreite.

Zum Glück benötigt unser Objekt nur knapp ein 443,2 MBytes an Bandbreite. Da reicht AGP 2x.

Was sind High Order Surfaces ?

DirectX 8 unterstützt 2 Arten von High Order Surfaces oder auch Curved Surfaces. Natürlich gibt es noch mehr, doch wie wollen es bei diesen zwei belassen.

• N-Patches (wird von ATi unterstützt - TRUFORM

• Parametrical Surfaces / RT-Patches (wird von NVIDIA unterstützt

Zunächst erstmal etwas allgemein zu Flächen höherer Ordnung. Die Ordnung gibt die Komplexität (Anzahl der Kontrollpunkte steigt der Fläche / Kurve an.



DirectX unterstützt Kurven 1er, 3er und 5er Ordnung. Je nach Kurvenart, haben Kontrollpunkte verschiedene Auswirkungen.



Es gibt natürlich noch mehr, z.B. B-Splines, NURBS (Non Uniform Rational B-Splines, Catmull-Rom Splines, .... je nach Anwendungsgebiet sind einige besser für Flächendarstellungen geeignet, gerade wenn mehrere Flächen benachbart sind, dort entstehen nämlich oft Lücken, da die Kurvenverläufe, der einzelnen Flächen, nicht passen. DirectX beherrscht Kurven / Flächen vom Typ Bezier und B-Spline.

Parametrical Surfaces (RT-Patches

Hier sehen wir ein Fläche (3er Ordnung, welche aus 4 Bezierkurven zusammengesetzt ist. DirectX kennt aber auch noch Flächen, mit einer höheren Ordnung (5er, womit dann jede Fläche noch mehr Kontrollpunkte besitzt und somit besser manipuliert werden kann.
Somit können komplexe Objekte mit wenigen Kurven beschrieben werden, was den AGP Bus entscheident entlastet. Man braucht ja nur die Anzahl der Dreiecke mit der Anzahl der Kontrollpunkte zu vergleichen, der Unterschied ist gigantisch. Ein weiterer Vorteil besteht darin, dass man die Anzahl der Dreiecke pro RT-Patch stufenlos variieren kann.



Hierbei wurde für jedes RT-Patch immer die Anzahl der Dreiecke um 2 erhöht. Dies könnte man aber auch für jedes RT-Patch einzeln, z.B. die dem Betrachter zugewandte Seite. Somit gibt es keine hässlichen auf "aufklapp" Effekte. Beim LOD (Level of Detail werden 3D-Modelle nur feiner oder gröber aufgelöst, es entstehen keine neuen Details.
Leider haben RT-Patches den Nachteil, dass man 3D-Modelle mit Kurven designen muss und wenn keine Hardwareunterstützung vorliegt, dann müssen die Kurven per CPU in Dreiecke umgerechnet werden (Tessellation, was aber bei DirectX vom Programmierer zu erledigen ist.

N-Patches

N-Patches oder wie ATi es nennt "TRUFORM" haben einen entscheidenten Vorteil gegenüber den RT-Patches, man muss die 3D-Modelle nicht verändern oder mit Splines / Kurven designen. Man kann ganz normale 3D-Modelle aus jedem Spiel nehmen und sie per N-Patch verfeinern.

So behauptet es ATi jedenfalls. Natürlich stimmt diese Aussage nicht ganz, doch dazu später mehr.
Schauen wir uns erstmal an, wie es funktioniert.



Jedes Dreieck wird mit 10 Kontrollpunkten unterteilt.



Dabei entscheidet die Stellung der Vertexnormalen (rot, wie sich die Biegung des entgültigen N-Patches verhält. Zusätzlich legt der Programmiere jetzt noch die Unterteilung der einzelnen Dreiecke fest, denn je feiner ein Dreieck unterteilt wird, umso runder wirken die Krümmungen.



Auch erkennt man recht gut, wie sich die Reflexionseigenschaften verbessern, je feiner die Dreiecke unterteilt werden. Zum Schluss wird noch die Interpolationsart der Normalen eingestellt, die sich ja über die gesamte Fläche verteilen.



Also nur Vorteile? Nein leider nicht.
Schauen wir einmal hier....



Dieser Fehler zeigt deutlich, wo das Problem bei N-Patches liegt, nämlich bei der Verbindung zweier Flächen, die durch gemeinsame Eckpunkte, die selben Normalen benutzten.



Bei 24 Eckpunkten hat jede Fläche ihre eigenen Eckpunkte, somit auch ihre eigenen Normalen. Der Würfel bleibt also erhalten. Es können auch Löcher entstehen, wenn nicht alle Normalen stimmen. Eine Fläche bleibt z.B. flach, wären eine angrenzende aufgewölbt wird. So etwas muss man beim modellieren beachten. Stufenloses LOD ist mit N-Patches leider nicht möglich.

Fazit

Wie man sieht, sind beide Verfahren nicht ohne Probleme. Mich wundert nur, dass ATi genau dieses 3D-Modell genommen hat, um TRUFORM zu demonstrieren, wo es doch eigentlich ein Beispiel für eine Fehlinterpretation ist. Egal, so auffällig ist es ja nicht. Es ist zwar lobenswert, dass Microsoft es geschafft hat, beide Verfahren in DirectX 8 zu integrieren (sind in OpenGL dank Extensions auch kein Problem, andererseits hat Microsoft es aber nicht fertig gebracht, beide Verfahren als Pflicht zu erklären, um als voll DirectX 8 kompatibel zu gelten. So hat ATi das eine und NVIDIA das andere Verfahren integriert. Ich bin der festen Ansicht, dass sich N-Patches leichter durchsetzten werden. Die RT-Patches werden erst breite Verwendung finden, wenn mehr Hersteller sie in ihre GPU's integrieren. Schade, hier geht der Vorwurf also direkt an ATi. Bleibt abzuwarten, wie es bei anderen Herstellern (BitBoys, ST MICRO) aussieht.