Die sieben goldenen Regeln

Aus EEP Wiki
Wechseln zu: Navigation, Suche

1 Objekt = 1 RGD


Goldene1.jpg

Die Objekte (die *.obj-Dateien im Home-Nostruktor 13.0 bzw. die *.mod3-Dateien in EEP), die als Baugruppen auf dem Basiskreuz oder auf mehreren Bewegungsachsen liegen, sollten nur aus einem Konstrukt, d.h. aus einem sogenannten RGD bestehen. Im Optimalfall ist die Anzahl der RGD's und die Anzahl der Objekte in einem Modell identisch. Dieses Optimum ist nur dadurch zu erzielen, dass alle Instanzen aller Objekte in einem Modell hundertprozentig identisch eingestellt werden, und zwar nach Möglichkeit mit der Face-Culling-Einstellung Rückseite und der Ausleuchtungsoption nach Normalen. Werden Instanzen mit unterschiedlichen Einstellungen verwendet, führt dies automatisch zur Bildung weiterer RGD's und damit zwangsläufig zu spürbaren Performance-Einbußen, da jedes neue RGD einen weiteren Multiplikator der Rendering-Pipeline darstellt. Die, mit dem Home-Nostruktor 13.0 gebauten Objekte sollten darüber hinaus in der sogenannten "Zwiebel-Bauweise" konstruiert werden, was im Volksmund etwa dem "Maleralgorithmus" entspricht. Das bedeutet konkret, dass die Reihenfolge der Polygon-Schichten von innen nach außen erfolgt. Auf diese Weise lassen sich mögliche Fehldarstellungen im Bezug auf die Entfernung der Flächen zueinander vermeiden. Das Problem der Gleitkomma-Genauigkeit bei der Tiefen-Berechnung ist seit EEP 7.0 dadurch gelöst, dass die Kamera nicht mehr in den entferntesten Winkel der Anlage wandert, sondern die Anlage gewissermaßen unter der Kamera "schwenkt". Doch in vielen Fällen lässt sich mit Hilfe der "Zwiebel-Bauweise" die Erzwingung eines Z-Offsets vereiteln. Damit ist gewährleistet, dass keine Instanzen mit unterschiedlichen Einstellungen und damit auch keine weiteren RGD's entstehen können. Das Funktionsprinzip der "Zwiebel-Bauweise" mitsamt ihren Vorzügen und Tücken wird in einem eigenen Kapitel noch ausführlich erläutert.


Konsequenter Einsatz von LOD's bei allen EEP-Modellen

Goldene2.jpg

Trotz der weiter steigenden Möglichkeiten im Bereich der 3D-Grafik ist bei der Darstellung einer komplexen virtuellen Szene immer noch die Grafik-Leistung ein Flaschenhals. Deshalb gibt es Möglichkeit, vor der Darstellung von Objekten diese für die Grafikhardware zu optimieren, in dem man für jedes Modell bis zu vier Qualitätsstufen erstellt, die bei zunehmender Entfernung zum Betrachter automatisch getauscht werden. Grundsätzlich gilt, dass jedes Modell, welches mehr als 300 Dreiecke des Drahtgitters aufweist, über mindestens einen LOD, also eine qualitativ vereinfachte Version des Hauptmodells verfügen muss. Der Grad der Vereinfachung und die Entfernung zum Betrachter, bei der die nächste Qualitätsstufe getauscht wird kann zwar von Modell zu Modell variieren, in der Hauptsache geht es jedoch darum, dass bei mittel und weit entfernten Objekten (> 750m) nur noch ein kleiner Bruchteil der ursprünglichen Geometrie (der Vertex- und Dreieckanzahl) berechnet wird.


1 Modell = 1 Textur

Goldene3.jpg

Das komplette 3D-Modell - die Objekte auf Achsen eingeschlossen - wird mit nur einer Textur belegt. Dies impliziert, dass alle Vertices des Drahtgitters eine gültige Textur-ID aufweisen. Schon bei der Planung, spätestens aber bei der Erstellung der Textur sollte man darauf achten, dass: 1. alle Bestandteile des Modells mit einer einzigen, angemessen klein dimensionierten Textur abgebildet, und 2. mögliche Kachelungen (Wiederholungen eines Motivs oder eines geometrischen Musters) direkt in die Textur eingearbeitet werden.

Wenn mehrere Texturen verwendet werden, was der früheren, heute veralteten und nicht mehr angemessenen Bauweise entspricht, wird der Home-Nostruktor 13.0 die vorkommenden Einzeltexturen zu einer globalen Modelltextur zusammen zu fassen versuchen, um deren Anzahl zu minimieren. Dies resultiert ebenfalls aus der Tatsache, dass die Anzahl der verwendeten Texturen einen Multiplikator der Rendering-Pipeline darstellt. Die Zusammenfassung erfolgt automatisch, wenn die Einzeltexturen nicht öfter als 15 mal gekachelt werden. Wird dieses Limit überschritten, wird die Textur automatisch ausgelagert, was das Rendern um die Anzahl der "verbannten" Texturen verlangsamt.


Von der Vernunft dimensionierte Textur

Goldene4.jpg

Die Empfehlung "angemessen klein dimensioniert" nennt kein Maß, sondern appelliert an die Kompromissbereitschaft und an die Vernunft des Konstrukteurs. Die bisher verbindliche Obergrenze von 512 x 512 Pixeln wurde aufgehoben, so dass jetzt auch Größen von 800 x 800 oder/und 1024 x 1024 Pixeln verwendet werden können. Dabei sollte man aber bedenken, dass eine Texturengröße von 256 x 256 Pixeln sowohl Hardware- als auch softwarebedingt das beste Resultat in Bezug auf Rechengeschwindigkeit, Dateiadressierung und Darstellungsqualität innerhalb der Fläche erzielt. Solange von einem 32-Bit-System auszugehen ist, wird sich daran auch nichts ändern.

Beim Export von Modellen - vor allem dann, wenn diese trotz der geltenden Empfehlung mehrere Texturen aufweisen - muss unbedingt darauf geachtet werden, dass die Dimensionen der erzeugten globalen Modelltextur die Größe von 2048 Pixeln nicht überschreiten, da es noch Grafikkarten bzw. Onboard-Grafikchipsätze gibt, die Texturen in derartiger Größe überhaupt nicht oder nur bedingt verarbeiten können. Dies könnte zu einer fehlerhaften Wiedergabe des Modells oder sogar zu einem Programm- oder Systemabsturz führen.

Die Dimensionen (Breite x Höhe) der erzeugten Modelltextur werden im Dialogfenster der Exportfunktion angezeigt und auch im Info-Log-File im Release-Ordner gespeichert - z.B unter einem Eintrag wie "Erzeugen der globalen Modelltextur: Sys_262.dds [DXT5] (1088x544)". Sollte es tatsächlich so weit kommen, dass eine oder gar zwei Dimensionen der Modelltextur das Limit von 2048 Pixeln überschreiten, sollten Sie unbedingt eine andere Skalierungsoption wählen. Die Standardvorgabe für die Skalierung liegt bei 100%, was sinngemäß den Originaldimensionen entspricht; ebenso können Sie aber auch die Skalierung von 75%, oder 50% wählen.


Nutzung der Texturkompression beim Export

Goldene5.jpg

Auch wenn die S3TC-Texturkompression verlustbehaftet ist und Kompressionsartefakte hervorbringt, bleibt sie dennoch das meist genutzte Verfahren, das sowohl von Microsoft in DirectX aufgenommen als auch von allen Grafikkarten- und Grafikchip-Herstellern als Dekomprimierungsalgorithmus implementiert wurde. Was dieses Verfahren auszeichnet, ist die konstante Komprimierungsrate, der geringe Speicherbedarf und vor allem die geringe Speicherbandbreite, die für die physikalische Dateigröße und deren Adressierung von Vorteil ist und bei unkomprimierten Texturen meistens zu einem "Flaschenhals" in der 3D-Berechnung führt.

Im Home-Nostruktor 13.0 ist die Komprimierung der Textur(en) beim Export die Standardeinstellung, die unbedingt auch genutzt werden sollte. Opake Texturen werden im DXT5-Format, nicht-opake in DXT1-Format gespeichert. In der tabellarischen Übersicht sind die Zusammenhänge zwischen den Dimensionen einer Textur und den verwendeten Kompressionsverfahren zu sehen. Sollten Sie sich für die Publikation eines Modells ohne Texturkompression entscheiden, muss dies bei der Modellinstallation hervorgehoben und gekennzeichnet werden. Ebenso können Sie ein derartiges Modell auch unter gleichem Namen, aber mit Texturkompression anbieten, so dass die Wahl dem Anwender überlassen bleibt.


Anzahl der Achsen-Objekte gering halten, reservierte Namen beachten

Goldene6.jpg

Die Anzahl der Achsen-Objekte (der sogenannten Kreuze) ist ebenfalls ein Multiplikator der Rendering-Pipeline. Daraus folgt, dass ein Modell nur so viel wie nötig und so wenig wie möglich Achsen-Objekte enthalten sollte. Der Aufbau von Modellen, bei denen die Objekte - aus Bequemlichkeit oder aus Unkenntnis - auf unbeweglichen Achsen platziert wurden, sollte der Vergangenheit angehören und in jedem Fall vermieden werden. Vorgefertigte Teilobjekte, die unbeweglich bleiben sollen, lassen sich schnell und mühelos in andere Objekte bzw. in das Basis-Objekt importieren. Beim Aufbau von Lichtsignalen für EEP ab Version 7.0 sollten Sie sogenannte Signal-Licht-ID's nutzen, die - im Unterschied zu früheren Programmversionen bis EEP 6.0 - nicht über bewegliche Achsen gesteuert werden. Dies trägt entscheidend zu einer höheren Berechnungsgeschwindigkeit bei und verbessert die Lesbarkeit der Signalbilder.

Bei der Benennung von Achsen-Kreuzen sind reservierte Achsennamen wie z.B. "Wasser" zu beachten, die ausschließlich für ganz bestimmte Effekte oder Funktionen benutzt werden dürfen. Auch die übliche Computer-Schreibkonvention, die keine deutschen Umlaute, Leerzeichen oder Sonderzeichen erlaubt, sollte beachtet werden. Alias-Namen für bewegliche Achsen, die vom Anwender gesteuert werden sollen, sind in der externen INI-Datei des Modells zu hinterlegen. In dieser Datei, die zur Beschreibung und Lokalisierung der Namen bestimmt ist, dürfen Umlaute und Sonderzeichen hingegen verwendet werden.


Beleuchtung über gleichfarbige Vertices

Goldene7.jpg

Bei der Beleuchtung von Modellen mit gängigen Beleuchtungs- und Signal-ID's (z.B. für die Spitzenbeleuchtung einer Lokomotive oder die Innenbeleuchtung eines Hauses) empfiehlt es sich, allen Vertices der beleuchteten Polygone eine einheitliche Farbe zuzuweisen, um die internen Farbregister möglichst klein zu halten. Sind alle Vertices einer beleuchteten Polygon-Fläche gleichfarbig, verläuft das Rendern des Drahtgitters wesentlich schneller. Mögliche Farb- oder Helligkeitsnuancen innerhalb eines Polygons sollten deshalb in der Textur verwirklicht werden und nicht über das übliche Smooth-Shading, das einen Farbverlauf zwischen den Vertices erzeugt. Hierbei ist die Länge und vor allem die Anzahl der Farbregister entscheidend, die für jede Farbe als separate Adresse mitgeführt werden müssen. Sind drei Vertices eines Primitivs gleichfarbig, genügen drei Farbregister; andernfalls, müssen alle Zwischenwerte ermittelt und jeweils als zusätzliche Adresse mitgeführt werden.



Mathematische Formel der Rendering-Pipeline


In der bisherigen Abhandlung war mehrmals davon die Rede, dass der eine oder andere Umstand einen Multiplikator der Rendering-Pipeline darstellt. Auch wenn die Rendering-Pipeline eine relativ komplizierte Angelegenheit ist, können die einzelnen Schritte, die zur 3D-Darstellung eines Modells führen, in eine einfache und für jedermann verständliche Gleichung gefasst werden, nämlich:

(Anzahl RGD's) x (Anzahl Texturen) x (Anzahl Achsenmodelle) = Anzahl der Pipelinefüllungen

Übertragen auf die Praxis heißt das: Wenn Sie alle oben aufgeführten Empfehlungen beherzigen und einen wunderschönen Bahnhof bauen, der auf dem Basis-Kreuz steht, sich mit nur einer Textur begnügt und die erforderlichen Instanziierungseigenschaften und damit nur ein RGD im Objekt aufweist, wird dieser zu einem "Musterbahnhof", da er die Rendering-Pipeline nur einmal durchläuft und in der höchstmöglichen Geschwindigkeit berechnet wird! Die mathematische Gleichung dafür lautet: 1 x 1 x 1 = 1.

Wir sind zwar keine Fatalisten, dürfen uns aber dennoch den GAU vorstellen, bei dem nicht Sie, werter Leser, sondern ein "Anleitungenleseverweigerer", der von all dem nichts weiß, einen optisch ebenfalls wunderschönen Bahnhof konstruiert. Diesen bestückt er in seiner Arglosigkeit mit sechs unbeweglichen Achsen, auf denen jeweils ein Wartehäuschen, eine Leuchte und eine Fahrplan-Tafel zu bewundern ist. Da er diesen Objekten auch noch Instanzen mit unterschiedlichen Einstellungen verpasst, etwa: (kein Face-Culling) + (Face-Culling Rückseite) + (Face-Culling Rückseite mit Z-Offset), entstehen gleich noch jeweils drei zusätzliche RGD’s. Zu allem Überfluss ist dem guten Mann auch nicht klar, dass die wiederholbaren Texturen, die er für die Dachsteine, den Wandputz und die Gehwegplatten auf dem Bahnsteig gewählt hat, nicht öfter als 15 mal wiederholt werden dürfen. Und so nimmt er ahnungslos in Kauf, dass nicht eine, sondern vier Texturen berechnet werden müssen. Die Gleichung für die Berechnung lautet in diesem Falle:

(3 RGD's) x (4 Texturen) x (6 unbewegliche Achsen) = 72 Pipelinefüllungen

In Worten heißt das, dass der wunderschöne Bahnhof sage und schreibe 72 mal die Rendering-Pipeline durchqueren muss, bevor er in EEP in der 3D-Ansicht dargestellt werden kann!


Zurück zur Startseite