.:.  Edgar Wood  .|.  Kuid-Liste  .|.  Downloads  .|.  Projekte  .|.  Tutorials  .|.  Links  .|.  Kontakt  .|.  SiteMap  .:.
   EW-Logo
 Edgar Wood
 Trainz
Ich baue für...
 ...diese Trainz-Versionen
 
    0


.:. Tutorial Polygonanzahl und Texturgröße .:.

 Trenn-Schiene

Erlaubte Bild-Formate für Texturen...

Content Creatoren (CCs, Objekt-Ersteller) für Trainz, texturieren Ihren Content (Assets, Objekte) mit Bild-Dateien.
Die empfohlenen Grafik-Formate sind...

  • TGA ― 24 Bit Farbtiefe
    Für das allgemeine äußere Erscheinungsbild des Objektes.
  • TGA ― 32 Bit Farbtiefe
    Für das allgemeine äußere Erscheinungsbild des Objektes, mit integriertem Alpha-Kanal.
    Seit TS2009, ausschließlich für Normal-(Bump-)Map-Texturen, mit denen 3D-(Licht-/Schatten-Struktur-)Effekte optisch simuliert werden.
    Der hier zu integrierende Graustufen-Alpha-Kanal, steuert die Helligkeit beziehungsweise das Glanz-Verhalten der Strukturen.
  • BMP ―   8 Bit Farbtiefe
    Für einen Graustufen-Alpha-Kanal, auch Blending-Alpha genannt, oder einen Alpha-Kanal in reinem schwarz & weiß, auch Alpha-Cut genannt.
    Seit TS2009, ist Blending-Alpha nicht mehr empfohlen beziehungsweise erlaubt.
  • BMP ― 24 Bit Farbtiefe
    Für Glanz-Effekte des äußeren Erscheinungsbildes.

...und seit TS2009 ist auch das Format...

  • JPG ― 24 Bit Farbtiefe
    Für Texturen, die nicht sonderlich detailreich sein müssen, weil nicht wirklich verlustfrei komprimierte Bild-Ergebnisse entstehen, selbst wenn '100% Qualität' beim erstellen angewendet wird.

...erlaubt.

Um aus diesen 'Bildern' Trainz-taugliche Texturen zu bekommen, wird zusätzlich noch eine gleichnamige Text-Datei mit einer Art technischer Beschreibung der Grafik benötigt, die aber beim 3D-Mesh-(Objekt-Außenhaut-)Export aus einem 3D-Modellier-Programm, automatisch angelegt wird.
Erstellt ein CC ein Objekt ohne 3D-Mesh, beispielsweise eine Boden-Textur, muss er diese Text-Datei selbst produzieren.
Diese Text-Datei trägt anstelle der Bild-Datei-Endung, zwei Datei-Endungen...

  • texture.txt


Ab TS2009, wurde es performanter...

Wird ein Objekt mit dem ContentManager - ab TS2009 - eingebunden, wird jede Grafik der oben genannten Formate, unter zuhilfenahme der entsprechenden texture.txt, in ein DirectX-kompatibles Grafik-Format konvertiert, welches die Datei-Endung...

  • texture

...bekommt.

Das Ergebnis daraus, ist durch Kompression in der Daten-Menge, durchschnittlich um Faktor vier reduziert, wird von Trainz ohne Umrechnung direkt in den Grafikkarten-Speicher geschoben, bietet außerdem automatisches Textur-LOD (Level Of Detail), welches die Grafikkarte selbstständig errechnet und verwaltet.
Der positive Nebeneffekt ist, dass nur noch die Textur geladen wird, wodurch die texture.txt weder geladen noch ausgewertet werden muss, was auch den Festplatten-Zugriff stark reduziert.
Der insgesamt beträchtliche Performance-Gewinn, ist sicher leicht erkennbar.

Die ursprünglichen Grafiken, nebst zugehöriger texture.txt, werden zwar von Trainz aufbewahrt, aber Trainz arbeitet intern ausschließlich mit den konvertierten Texturen.


Der Vollständigkeit halber sei erwähnt, dass es bereits vor TS2009, ein Trainz-Texture(n)-Format gab.
Schon hier wurde die Datei-Endung 'texture' verwendet. Hierbei handelte es sich allerdings um ein binäres Format, welches noch keine Kompression sondern lediglich die texture.txt-Integration mitbrachte.
Dieses Format war beinahe ausnahmslos dem BuiltIn-Content (mitgelieferte (eingebaute) Objekte) vorbehalten.
Wollte ein CC dieses Format für seine eigenen Objekt-Texturen nutzen, musste er sich selbst um dessen Konvertierung und anschließender Beseitigung der ursprünglichen Grafik(en) und der jeweiligen texture.txt kümmern.


EW

 Trenn-Schiene

Erlaubte Trainz-Textur-Größen nach 'Fakultät 2'...

  8 Pixel Breite und/oder Höhe = Mindestmaß
2 x 8 Pixel Breite und/oder Höhe = 16 Pixel
2 x 16 Pixel Breite und/oder Höhe = 32 Pixel
2 x 32 Pixel Breite und/oder Höhe = 64 Pixel
2 x 64 Pixel Breite und/oder Höhe = 128 Pixel
2 x 128 Pixel Breite und/oder Höhe = 256 Pixel
2 x 256 Pixe Breite und/oder Höhe = 512 Pixel
2 x 512 Pixel Breite und/oder Höhe = 1.024 Pixel
2 x 1.024 Pixel Breite und/oder Höhe = 2.048 Pixel
2 x  2.048 Pixel Breite und/oder Höhe =  4.096 Pixel

Seit TS2009 haben Texturen bis 4.096 Pixel Breite und/oder Höhe einzug gehalten, wobei vorher lediglich 1.024 Pixel erlabt waren.
2.048 Pixel waren vor TS2009 ausschließlich dem Objekt-Typ 'Backdrop' vorbehalten.


Textur-Größen-Rechner...

 8 Pixel Breite 
 16 Pixel Breite 
 32 Pixel Breite 
 64 Pixel Breite 
 128 Pixel Breite 
 256 Pixel Breite 
 512 Pixel Breite 
 1024 Pixel Breite 
 2048 Pixel Breite 
 4096 Pixel Breite 
8 Pixel Höhe
16 Pixel Höhe
32 Pixel Höhe
    64 Pixel Höhe
= 1:1
= 1:2
= 1:4
= 1:8


Erlaubte Trainz-Textur-Seitenverhältnisse...

Wie Du an der errechneten Tabelle erkennen kannst, ist der erlaubte Unterschied zwischen Breite und Höhe (Seiten-Verhältnis)...
1:1, 1:2, 1:4 & maximal 1:8
...oder...
1:1, 2:1, 4:1 & maximal 8:1.

Beachte also...
Überschreiten Sie den genannten Bereich nicht, um Performance-Verluste oder untexturierte (weiße) Objekt-Flächen zu vermeiden.


EW

 Trenn-Schiene

Texturgröße?

Immer wenn wir eine Größenangabe bei Texturen finden, erkennen wir eine Rechenaufgabe.
Beispielsweise: 1.024 x 1.024 Pixel x 24 Bit Farbtiefe.

Machen wir uns, zum besseren Verständnis, einmal die Mühe die offensichtliche Aufgabe zu lösen...
1.024 x 1.024 = 1.048.576 Pixel.

Die 24 Bit Farbtiefe, teilen wir in Bytes auf...
24 / 8 = 3, da ein Byte aus 8 Bit besteht.

Zurück zu unserer Rechnung:
1.048.576 Pixel x 3 Byte Farbtiefe = 3.145.728 Byte oder
3.145.728 Byte x 8 Bit = 25.165.824 Bit.

Lesen wir diese Zahlen einmal etwas anders...
3 Millionen, 145 Tausend und 728 Byte beziehungsweise
25 Millionen, 165 Tausend und 824 Bit.
Das ist doch schon eine beeindruckende Zahl, oder?

Haben wir jetzt aber eine Farbtiefe von 32 Bit, weil wir eine Alpha-Kanal-Textur vorliegen haben, sind es bereits
4.194.304 Bytes oder 33.554.432 Bit.

Auch hier zum bewusst werden...
4 Millionen, 194 Tausend und 304 Byte beziehungsweise
33 Millionen, 554 Tausend und 432 Bit.
Ein schwerer Brocken.

Bedenken wir, dass diese Datenmenge zuerst von der Festplatte in den Hauptspeicher geladen werden muss, um dann eine Kopie dieser Daten in den Grafikkartenspeicher verschoben werden muss, der im übrigen auch noch dazu kleiner ist als das Rechner-Ram, vergeht etwa soviel Zeit, wie die CPU unseres Rechners benötigt um vielleicht 5.000 Mesh-Poligone zu berechnen.

Vergleichen wir die reinen verwertbaren Datenmengen von einigen zulässigen Texturgrößen...
1.552 Bit oder
6.144 Bit oder
24.576 Bit oder
98.304 Bit oder
393.216 Bit oder
1.572.864 Bit oder
6.147.456 Bit oder
25.165.824 Bit oder
100.663.296 Bit oder
402.653.024 Bit oder
194 Byte oder
768 Byte oder
3.072 Byte oder
12.288 Byte oder
49.152 Byte oder
196.608 Byte oder
768.432 Byte oder
3.145.728 Byte oder
12.582.912 Byte oder
50.331.648 Byte oder

0,19 KB sind es bei
0,75 KB sind es bei
3,00 KB sind es bei
12,00 KB sind es bei
48,00 KB sind es bei
192,00 KB sind es bei
750,42 KB sind es bei
3.072,00 KB sind es bei
12.288,00 KB sind es bei
49.152,00 KB sind es bei

8 x
16 x
32 x
64 x
128 x
256 x
512 x
1.024 x
2.048 x
4.096 x

8 Pixeln
16 Pixeln
32 Pixeln
64 Pixeln
128 Pixeln
256 Pixeln
512 Pixeln
1.024 Pixeln
2.048 Pixeln
4.096 Pixeln

...bei jeweils 24 Bit Farbtiefe.

Die Zahlen sprechen wohl für sich.

Seit TS2009, kann man die Sache jedoch etwas gelassener betrachten, wenn wir an die weiter oben erwähnte Textur-Konvertierung beim einbinden denken.


EW

 Trenn-Schiene

Grundsätzliche Überlegungen zu Polygonanzahl und Texturgröße

Nicht selten findet man bei Contentvorstellungen im Forum von einem Leser die Frage, "wie viele Polys hat Dein Objekt überhaupt". Diese Frage ist durchaus berechtigt - jedoch sagt eine Antwort darauf aber dennoch nichts über die Performancefreundlichkeit aus. Als Beispiel möchte ich hier mal einen Autokäufer zitieren, der mit Sicherheit nicht nur die Anzahl der Pferde, die unter der Haube stecken, von dem Objekt seines Interesses erfahren will. Vielmehr wird er noch nach anderen Kriterien wie Hubraum usw. nachfragen, um sich ein Bild von der Leistungsfähigkeit machen zu können.

Genauso verhält es sich mit dem Content auch. Ein Objekt besteht nicht nur aus Polygonen, sondern auch aus anderen Elementen, die die Leistungsfähigkeit in erheblichem Maße beeinflussen können. In erster Linie sind hier die Texturgrößen und auch die Anzahl der Materials zu nennen. Aber auch eigebettete Scripte, Alphakanäle und der gleichen können hier genannt werden.

Zum besseren Verständnis hole ich jetzt einwenig weiter aus. Grundsätzlich kann jedes Objekt ohne jegliche Texturierung dargestellt werden, indem jede noch so kleine Winzigkeit gemesht wird. Stellt sich jetzt die Frage, warum dann überhaupt Texturen benötigt werden. Durch die gerade beschriebenen hoch detaillierten Meshes ohne Texturen wird die Polygonanzahl in aller Regel dermaßen in die Höhe getrieben, daß dadurch mit Performanceeinbußen gerechnet werden muß. Viele "Feinheiten" eines Objektes kann man aber mittels eines Bildes, das auf ein oder mehrere Polygone projiziert wird, ersetzen, womit eine drastische Senkung der Polygonanzahl erreicht werden kann.

Die Verarbeitung solcher Texturen erfolgt in aller Regel recht fix, solange diese im Speicher der Grafikkarte gehalten werden können und stellen dadurch eine echte Bereicherung der Performance dar. Aber man darf nicht vergessen, das sie aus Bildern (Bitmaps) bestehen, die im Gegensatz zu den Koordinaten eines Polygones sehr viel mehr des äußerst knappen Speicherplatzes in den Grafikkarten beanspruchen. Und wenn dieser Speicher voll ist, dann muß der doch relativ langsame Arbeitsspeicher herhalten. Und wenn dieser dann voll ist, dann wird ausgelagert auf die Festplatte, welche die Daten nur im "Schneckentempo" weitergibt.

Hieraus ergibt sich zwangsläufig schon jetzt die Frage nach einem "ausgewogenen Verhältnis" zwischen Polygonanzahl und Texturgrößen. Auf der einen Seite will man Polygone durch Texturen ersetzen, welche aber andererseits die "schnellen Speicher", welche sowieso nur in begrenzter Größe vorhanden sind, sehr schnell füllen.

Ein solches ausgewogenes Verhältnis zu finden, ist aber gar nicht so schwer, wenn man sich daran erinnert, daß ich oben erwähnt habe, daß mit den Texturen lediglich die "Feinheiten eines Objektes" dargestellt werden sollen. Außerdem belasten die Polygone ohnehin das System nicht so drastisch, wie allgemein immer angenommen wird. Die Algorythmen, die für deren Berechnung verwendet werden, arbeiten sehr effektiv; das Projizieren der Texturen hingegen stellt da schon eine wesentlich größere Hürde dar.

Die Findung und Durchsetzung eines solchen "ausgewogenen Verhältnisses" bezeichne ich als "texturorientiertes Meshen". Das heist, daß vor dem ersten Zeichnen eines Polygones in einem CAD-Programm bereits das äußere Erscheinungsbild des Objektes bereits so "zerlegt" sein muß, daß dieses mit wenigen, kleinen bis sehr kleinen Texturen auskommt. Besonderes Augenmerk ist dabei darauf zu richten, daß Flächen so angeordnet werden, daß diese per Tiling mit winzigen Texturen gemappt werden können.

Das war bis jetzt sehr theoretisch. Als praktisches Beispiel nehme ich eine Hausmauer. Diese zerlege ich zuerst in die in Frage kommenden Einzelteile - und zwar nach dem Prinzip, daß nur Feinheiten texturiert werden und Tiling soweit wie möglich eingesetzt wird. Diese Hausmauer besteht - sagen wir mal - aus 1 Haustüre mit jeweils 2 Fenstern rechts und links und im Obergeschoss aus 5 Fenstern. Außerdem ist auf dieser Hausmauer Putz und Farbe aufgetragen, der auch dargestellt werden muß.

Die einfachste Möglichkeit, die aber davon zeugt, daß der Contentcreator sich keinerlei Gedanken um die Performance macht und sogar billigend in Kauf nimmt, daß andere User durch solche Objekte im Spielvergnügen beeinträchtigt werden, ist die, daß dafür zwei Polygone genommen werden, die mit einer Megabyte schweren Fotografie belegt werden. Außerdem ist eine solche Hauswand nicht nur extrem performancebelastend sondern nach wie vor ein 2-D Objekt. Wir haben aber vor, ein im Gegensatz dazu äußerst performancefreundliches 3D-Objekt auf die Platte zu stellen. Trainz ist schließlich eine 3-D Simulation und kein Grab für projizierte Fotografien. Wer 2-D bevorzugt, sollte dann doch auf ein Brettspiel wie Halma oder Monopoly zurückgreifen.

Aus der Überlegung heraus, daß die Texturen nur die "Feinheiten" darstellen sollen, bedingt natürlich, daß größere Wechsel in den Dimensionen als Mesh dargestellt werden müssen. Wo hier die Grenze ist, kann natürlich nicht beziffert werden. Das liegt einzig und allein an dem Objekt und natürlich am Autor. Jedenfalls kann mit Sicherheit davon ausgegangen werden, daß die Nischen, in denen die Fenster und die Tür sitzen, gemesht werden sollten. Das sind pro Fenster 10 Polygone mehr, die aber dem ganzen Objekt ein realistischeres und vor allem ein 3-D Aussehen geben, das sich drastisch von einem "tapezierten 2-D Würfel" abhebt. Wesentlich ausschlaggebender ist aber, daß wir dadurch schon die Texturgrößen auf einen Bruchteil gesenkt haben. Wir müssen jetzt nur noch eine einzige kleine Textur für ein Fenster fertigen, die dann sieben mal angewendet wird. Mit der Haustüre wird ebenso verfahren.

Jetzt bleibt nur noch der Putz zu texturieren. Dazu nehmen wir einen Ausschnitt aus der Mauerstruktur von ca. 1 mal 1 Meter und fertigen daraus eine kachelbare Textur, die wir weitgehend von Moiree befreien. Diese wird dann per Tiling gemappt.

Nun können wir mal den Vergleich anstellen. Aus einem Foto, das die gesamte Hausfront darstellt, haben wir lediglich 1 Fenster, 1 Türe und 1qm Putz benötigt. Und das ist eine gewaltige Einsparung an Speicherplatz und außerdem auch noch eine optische Bereicherung. Die wenigen hundert Polygone, die für das komplette. Haus mehr gebraucht würden, schaden der Performance jedenfalls nicht so stark, wie eine Megabyte große Textur.

Für dieses Beispiel dürfen nun am Ende nur 3 Materials (Fenster, Türe, Putz) im Materialnavigator vorhanden sein. Da mit jedem einzelnen Material auch die zugehörige Textur geladen wird - und zwar auch dann, wenn die Textur bereits schon in einem anderen Material verwendet wurde, ist hier unbedingt zu bereinigen. Wer das unterläßt, hat die ganze Mühe eines "texturorientierten Meshens" umsonst gemacht.


SD-Workz

 Trenn-Schiene
 DLS- und Forums-Banner in eigene Site einbinden
 Trenn-Schiene
 HL werbe + grafik design © 2005  bis  2024
Hartmut Lehmann