.:. Edgar Wood .|. Kuid-Liste .|. Downloads .|. Projekte .|. Tutorials .|. Links .|. Kontakt .|. SiteMap .:. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Texturgröße?Immer wenn wir eine Größenangabe bei Texturen finden,
erkennen wir eine Rechenaufgabe. Machen wir uns, zum besseren Verständnis, einmal die Mühe
die offensichtliche Aufgabe zu lösen... Die 24 Bit Farbtiefe, teilen wir in Bytes auf... Lesen wir diese Zahlen einmal etwas anders... Haben wir jetzt aber eine Farbtiefe von 32 Bit, weil wir eine
Alpha-Kanal-Textur vorliegen haben, sind es bereits Auch hier zum bewusst werden... 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...
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.
|
Grundsätzliche Überlegungen zu Polygonanzahl und TexturgrößeNicht 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.
|
© 2005 bis
2024 Hartmut Lehmann |