Bei aller Liebe.....

Zitat von Juergen

[...]Ja die 25 000 Grenze sollte man nicht überschreiten[...]

Diese Aussage stimmt so nicht. Sie repraesentiert aber leider das, was ich im allgemeinen als Polyphobie bezeichne.

Die Anzahl der Polygone eines Objektes sagt nicht direkt etwas ueber den Einfluss auf die Performance aus. Ja, es ist richtig, fast jedes Polyogon muss von der GPU dargestellt werden und beeinflusst damit natuerlich die Performance.

Aber z.B. gibt Nvidia fuer die GeForce GTX580 an, dass sie zwei Milliarden Polygone pro Sekunde Verarbeiten kann. Aktuelle andere GPU sind da aehnlich leistungsfaehig. Sprich, wir muessen uns ueber die Anzahl der Polygone bei Weitem nicht mehr die Gedanken machen wie zu Zeiten von TRS2004 und den damals aktuellen GPU.

Ich will nicht sagen keine Gedanken mehr, aber Panik ist nicht mehr noetig, wenn es mal ein paar tausend mehr sind.

Viel wichtiger ist die Frage wie ein CC mit den Polygonen umgeht.

Erstens sollten natuerlich Polygone, die aus keiner Ansicht heraus sichtbar sind, absolut tabu sein.

Zweitens kann man insbesondere bei Rohrleitungen, Gelaendern und aehnlichem mit sehr viel weniger Seiten und einem entsprechenden Smoothing optisch einen genauso hochwertigen Effekt erzielen, wie mit vielen Seiten/Polygonen (siehe Bild 02).

Und drittens ein Element, dass die meisten CC ziemlich oft voellig vernachlaessigen, die Vertices. Dies sind die Punkte, ueber die ein Polygon definiert wird.

Und hier faengt es an interessant zu werden. Wie stellt eine GPU einen Polygon dar?

Eine Stark vereinfachte Beschreibung.
Die Applikation uebergibt der GPU ein Array mit Vertex-Koordinaten an einen sog. Vertex-Shader, der entscheidet wie selbiger spaeter dargestellt werden soll und ihn in Bildschirmkoordinaten umsetzt. Die GPU gruppiert nun drei zuvor vom Shader bearbeiteten Vertices zu einem Polygon und entscheidet mit komplexem mathematischen Funktionen, ob das Polygon sichtbar ist. Wenn nicht, wird es verworfen.

Ist es sichtbar wird fuer jedes Polygon eine Art Setup durchlaufen und eine Definition desselben erzeugt. Ebenso wird errechnet wie sich das Polygon mit anderen auf dem Bildschirm verhaelt, ob es mit anderen ueberlappt usw. und es wird daraus ein sog. Fragment erzeugt.

Mit einem Fragment-Shader werden die Eigenschaften wie Farbe, Reflektionsgrad uvm. bestimmt. Die GPU kombiniert nun die Fragment-Farbe mit der korrespondieren Bildschirmpixelfarbe und den Eigenschaften des Fragmentes und das Polygon wird dargestellt.

Wie man erkennen kann, spielen die Vertices eine entscheidende Rolle, da aus ihnen erst zur Laufzeit aus einem 3D-Modell von der GPU eine Flaeche/Polygon errechnet und dargestellt wird. Die wesentlichen Eigenschaften einer Flaeche werden also in den Vertices gespeichert, durch die diese ja erst definiert wird.

Deshalb sollte es oberster Grundsatz eines CC sein alle Objekte eines Modelles, welche an irgend einer Stelle eine Verbindung haben, diese via Attach zu einem Objekt zusammenzufuehren und vor allen Dingen alle Vertices zu verschweissen (Weld)! Das reduziert die Anzahl der Vertices dramatisch und damit die Anzahl der Punkte/Vertices, die berechnet werden muessen.

Ein weiterer Performance-Vorteil bei verschweissten Vertices besteht in der Faehigkeit der GPU ein sog. Indexed-Drawing.

Normalerweise muss jeder Vertex den Shader-Prozess durchaleufen, aber eben nicht immer. Teilen benachbarten Flaechen/Polygone Vertices und sind diese in der 3D-Applikation verschweisst, dann kann die GPU auf dieses Indexed-Drawing zurueckgreifen und die schon zuvor errechneten Daten ohne Neuberechnung direkt verwenden. Das spart enorm Rechenzeit.

Summa summarum ist also nicht die so viel zitierte Anzahl der Polygone entscheidend, sondern die Anzahl der in einem Modell enthaltenen Vertices.

Ein kleines Beispiel dazu. In Bild01 ist eine Quadrat dessen eine Flaeche an der Achse 3/6 und 2/4 um 45 Grad gedreht ist dargestellt. Dieses Objekt besteht aus zwei Flachen (A und B). Die Flaeche A ist durch die Vertices 1, 2 und 3 definiert, die Flaeche B durch 4, 5 und 6. Das Mesh hat also sechs Vertices und zwei Polygone.

Exportieren wir das ganze nun hat die im-Datei eine Groesse von 492 Bytes.

Nun werden wir die Flaechen A und B via Attach zu einem Objekt verbinden. Als Resultat haben wir immer noch sechs Vertices und zwei Polygone und die exportierte im-Datei ist immer noch 492 Bytes gross.

Jetzt kommt der entscheidende Punkt. Im Vertex-Mode werden nun alle Vertices, die auf der exakt gleichen Position liegen mit Weld verschweisst. Daraus resultieren immer noch zwei Polygone, aber nur noch vier Vertices. Und die Im-Datei ist nur noch 428 Bytes gross.

Die Flaechen werden nun ueber die Vertices 1, 2, 4 und 2, 3, 4 definiert und nun kann die GPU auch auf das Indexed-Drawing zurueckgreifen und es muessen nur noch vier anstatt sechs Vertices den Shader durchlaufen.

Es sollte ganz gut erkennbar sein, wie man nun als CC performanter bauen kann...

======================================================

So, wenn wir uns erst einmal an den Gedanken gewoehnt haben, dass uns die absolute Zahl der Polygone nicht mehr allzu viele Sorgen machen muss, so obige Anregungen beruecksichtigt werden, dann koennen wir uns dem weitaus wichtigeren Thema im Zusamenhang mit Performance zuwenden.

Den Materialien! Bei diesem Thema besteht offenbar die groesste Verwirrung unter vielen CC.

Ein Material besteht im einfachsten Fall aus einem Farbwert einer monochromen Farbe. Hierfuer eine Textur zu verwenden ist ein absolutes No-Go! Es sollte immer ein Notex-Material verwendet werden. Der CM kreidet inzwischen monochrome Texturen oberhalb von 32x32 Pixeln als fehlerhaft ab. Gut, ein richtiger Schritt in diese Richtung!

Sollten in einem Asset mehrere monochrome Farben zum Einsatz kommen, ist es wiederum besser eine Textur zu verwenden, die schachbrettartig, ca 8x8 Pixel gross diese Farben enthaelt.

Ein Material kann auch aus einer oder mehreren Texturen bestehen. Im einfachsten Fall ist das eine Diffuse-Map. Es kann aber durchaus aus mehreren Texturen bestehen: Diffuse-Map, Opacity-Map, Reflection-Map, Bump-Map usf.

Sprich, die Anzahl der Texturen eines Assets ist nicht unbedingt die Anzahl der dort verwendeten Materialien und letztere ist entscheidend fuer die Performance. Je weniger Materialien ein Asset verwendet, desto besser ist in der Regel die Performance.

Ein besonderes Augenmerk sollte man auf die sog. Bump- oder Normal-Maps werfen. Sie ermoeglichen es enorm die Anzahl der Polygone zu reduzieren ohne auf ein detailliertes Aussehen verzichten zu muessen. Z.B. die Nieten auf einem Dampfkessel...
Dazu benoetigt man allerdings 3d-Software, die Render to Texture beherrscht, wie Blender und 3dsMax. Als Notbehelf fuer Gmax-User kann ein Programm wie ShaderMap2 oder die Nvidia Normal Map Filter dienen, welches erstaunlich gute Ergebnisse erziehlt, die allerdings an eine gerenderte Textur nicht heranreichen.

Zu den Texturen, respektive den Bitmap-Dateien.
Es ist auf jeden Fall besser wenige, im Idealfall nur eine, grosse Texturen/Textur zu verwenden, anstatt viele kleine!

TS2012 Verarbeitet eine maximale Texturgroese von 2048x2048. Es funktionieren auch groessere, diese zu verwenden ergibt aber keinen Sinn. Warum?

Seit TS2012 verwendet Trainz ein sog. Texture-Lod, d.h. grosse Texturen werden nur reduziert dargestellt und erst wenn man nahe genug an ein Objekt herankommt wird die volle Aufloesung benutzt. Leider werden 4096x4096 generell auf 2048x2048 heruntergerechnet. Leider sind auch die Reduktionsalgorithmen von Trainz nicht gerade State of Art, deshalb empfiehlt es sich in hoeheren Aufloesungen zu rendern und dann mit einer hochwertigen Grafiksoftware selber auf 2048x2048 zu reduzieren. Wenn es gar nicht anders geht, muessen eben zwei 2048er zum Einsatz kommen, was bei groesseren Objekten oft nicht zu vermeiden ist. Weil letztendlich will man ja auch hochwertige Assets bauen.

Es ja nicht darum um jeden Preis die Performance-Last eines Objektes zu druecken, sonder unnoetige Dinge, die auf Kosten der Performance gehen zu vermeiden!

Mick!