Zunächst wird der Rendervorgang im Detail (nur soweit, wie es hier für das Verständnis nötig wird, bei genauer Betrahtung wird die Liste etwas länger) geschildert, im zweiten Schritt folgen die Konsequenzen, die sich für uns dadurch ergeben.
Renderpipeline
Es wird jedes Dreiecks eines Modells einzeln betrachtet, DirectX zeichnet also einfach alle Dreiecke in gegebener Reihenfolge auf den Bildschirm.
Das läßt sich grob in zwei Schritte unterteilen:
1.) Vertextransformation
a) Transformation der Eckpunkte (Vertices) aus den Modellkoordinaten an die globalen Koordinaten (Lage in der 3D-Welt).
b) Transformation der Vertices vom 3D auf die Bildschirmkoordinaten. Dabei wird für jeden Vertex neben der x-y-Lage auch ein Farbwert berechnet. Dieser richtet sich nach den Materialeigenschaften, dem Winkel zwischen Licht und Normalenvektor des Vertex' und weiteren Rendereinstellungen (später mehr dazu). Ein Dreieck besteht jetzt also aus drei Punkten auf der Bildschirmfläche mit je einem Farbwert. Gezeichnet wurde bisher aber noch nichts, die Werte sind nur intern gespeichert.
Jetzt muß die Fläche des Dreiecks ausgefüllt werden
2.) Pixeltransformation
a) Prüfen, ob das Dreieck nach vorne oder nach hinten zeigt; wenn es nach hinten ausgerichtet ist -> Abbruch des Vorgangs - sonst: Alle Pixel der Dreieckfläche der Reihe nach durchgehen
b) Farbwert des Pixels bestimmen, indem entsprechend je nach Abstand zwischen den Farbwerten der drei Vertices interpoliert wird und zusätzlich die entsprechenden Texturinformationen hinzugezogen werden
c) Prüfen, ob das Pixel evtl. wegen eines weiter vorne liegenden Polygons gar nicht mehr gezeichnet werden darf (das macht der z-Buffer, der für jedes Bildschirmpixel einen Entfernungswert vom Auge speichert. Wenn an der Position unseres Pixels schon ein weiter vorne liegendes Pixel gezeichnet wurde, steht also ein kleinerer Wert im z-Buffer als unser Pixel aufweist). Wenn Pixel weiter vorne vorhanden -> Abbruch des Vorgangs
d) Zeichnen des Pixels auf den Bildschirm, Setzen des Abstandswertes im z-Buffer (damit das Pixel nicht von später noch zu zeichnenden weiter hinten liegenden Dreiecken überschrieben wird).
Das wäre der ganz normale Vorgang für nicht transparente Dreiecke. Allererster Schritt, den nicht DirectX sondern Zusi selbst vornimmt, wäre noch die Überprüfung, ob ein Modell überhaupt im Blickbereich liegt. Wenn das nicht der Fall ist (liegt im Rücken o.ä.), wird das Modell gar nicht erst weiter betrachtet.
Vergleich zu Zusi 2
Zunächst mal ein kleiner Rückblick auf Zusi 2: Bei Zusi 2 ist die Performance eines Modells im wesentlichen von der Anzahl der Vertices abhängig. Rechenzeitkritisch sind dort also die Punkte unter 1.)
Das Ausfüllen einer einfarbigen, texturlosen Fläche unter Schritt 2.b. geht rasend schnell. Das ändert sich mit den Texturen; man muß also jetzt nicht nur die Anzahl der Vertices im Auge behalten, sondern auch die auf dem Bildschirm auszufüllende Fläche. Wo man unter Zusi 2 evtl. mehrere Flächen hintereinandergesetzt hat, um Polygonecken zu sparen, kann es unter Zusi 3 sinnvoll sein, ein paar Polygonecken zu spendieren, um auszufüllende Fläche zu sparen.
Volltransparenz
Flächen mit volltransparenten Bereichen sind recht schnell abgehandelt: Bei 2.c. wird festgestellt, daß das Pixel transparent ist und der Vorgang abgebrochen. Das Pixel braucht damit weniger Rechenzeit als ein zu zeichnendes Pixel, das bis 2.d. durchgerechnet wird (die Technik, die den Abbruch hier ermöglicht heißt alpa-testing und sollte von allen Zusi3-tauglichen Karten unterstützt werden). Große transparente Flächen sind aber trotzdem nicht sinnvoll, denn immerhin wird auch für die transparenten Flächen von 1.a bis 2.c gerechnet.
Halbtransparenz
Der undankbarste Fall: 2.d. muß hier noch erweitert werden. Es wird also bei 2.c. ein Farb- und ein Halbtransparenzwert ("alpha") ermittelt. Entsprechend der Stärke der Halbtransparenz muß das schon vorhandene Pixel mit dem neuen Pixel gemischt werden. Also Auslesen des Farbwerts vom Bildschirm, Berechnen eines neuen Mischfarbwertes, Zeichnen des neuen Farbwertes, Setzen des Abstandswertes im z-Buffer (damit das Pixel nicht von später noch zu zeichnenden weiter hinten liegenden Dreiecken überschrieben wird).
Wie man schnell erkennt, das performancemäßig aufwendigste von allen.
Und wer gut aufgepaßt hat, sieht gleich ein weiteres Problem: Wenn zum Zeitpunkt der Farbmischung noch gar nicht alle Dreiecke gezeichnet wurden, die hinter der halbtransparenten Fläche zu sehen sein sollen, dann hat man ein Problem. Denn ein später gezeichnetes und weiter hinten liegendes Dreieck wird schon bei 2.c scheitern und damit keinen Einfluß mehr auf das Ergebnis haben.
Es gibt nur eine Maßnahme dagegen: Die Polygone müssen von hinten nach vorne sortiert werden.
Zusi macht darum folgendes:
- Das Terrain, das ja nicht transparent ist, wird zuerst von vorne nach hinten sortiert und gezeichnet. Das hat den Vorteil, daß relativ viele Punkte schon bei 2.c abbrechen können. Wenn man die Berge hingegen von hinten nach vorne zeichnen würde, würden fast alle Pixel bis 2.d durchlaufen, nur um dann doch später nch von den weiter vorne liegenden Bergen überschrieben zu werden.
- Die anderen Objekte hingegen werden von hinten nach vorne sortiert und gezeichnet. Damit ist bis auf (hoffentlich wenige) sehr spezielle Fälle sichergestellt, daß beim Zeichnen von halbtransparenten Flächen bereits alle dahinter liegenden Pixel gezeichnet wurden.
Wie es aussieht, wenn falsch sortiert wird, sieht man hier:
Da wurden zuerst die Drehgestellte gezeichnet. Die halbtransparenten Flächen wurden mit dem Himmel vermischt und im z-Buffer gegen Überschreiben durch weiter hinten liegende Poylgone gesichert. Dann wurde das Gleis gezeichnet, wobei die hinter den Drehgestellpolygonen liegenden Pixel wg. z-Buffer-Test bei 2.c nicht weiter verfolgt wurden. Fehler im Betrachter o.ä. (noch nicht untersucht), zumindest nicht vom Anwender zu beeinflussen.
Modelle mit Inneneinrichtung: Hier muß ja auch noch innerhalb des Modells die korrekte Reihenfolge sichergestellt werden. Das macht man über mehrere Meshes, die von innen nach außen gezeichnet werden. Die Reihenfolge der Meshes kann man in den ls3-Einstellungen der Datei festlegen. Ich werde morgen mal ein Beispiel mit Bildern dazu folgen lassen.
Carsten
![:]](./images/smilies/pleased.gif "Freude"){kind=small}
Oder es ist sonst irgendwas schiefgelaufen...