64 Bit Rendering - Sinn oder Unsinn?

26. Juli 2001 / von aths / Seite 1 von 2

John Carmack forderte das 64-Bit-Rendering. Das erscheint reichlich verwegen - und doch wird dieses Feature wohl mit dem kommenden DirectX9 Einzug halten. Doch bevor wir uns der technischen Seite zuwenden, ein Blick in die Praxis von "16 vs. 32 Bit":

Die Verdoppelung von 16 zu 32 Bit brachte nicht den grossen, umwerfenden Vorteil. Erst bei späteren Spielen, wie Quake3, sah man die Unterschiede auf den ersten Blick. Nun gibt es das sogenannte Gesetz des abnehmenden Ertrages. Eine weitere Farbtiefen-Verdopplung sollte also nicht den selben Qualitätsschub bringen. Doch diese Betrachtung vernachlässigt eine andere Entwicklung:

Als 3dfx mit der Voodoo2 das Multitexturing (Auftragen von mehreren Texturen auf einen Pixel in einem Takt) "for free" (ohne Leistungsverlust) einführte, wurde es modern, Dreiecke mit zwei Texturen zu versehen. Selbst heute, 5 Jahre (!) später, sind jedoch im Durchschnitt nur 2-3 Texturen pro Dreieck im Einsatz (Normal-Textur, Lightmap, eventuell Detail Map bzw. Bump Map). Doch der Entwicklungskreislauf dreht sich bekanntlich immer schneller. Kamen also in den letzten Jahren kaum Texturen-Schichten dazu, so kann sich dies schon bald ändern. Obwohl die momentane Entwicklung eher anders herum zu gehen scheint: Der Pixelshader macht z.B. zumindestens Lightmaps überflüssig, auch wenn sie nach wie vor noch in Masse eingesetzt werden.

Direkt nach der Einführung des 32-Bit-Renderings wurde gestreut, dass 16-Bit-Rendering altmodisch sei. In Wahrheit kam das neue Feature ja zunächst ohne spezielle Unterstützung seitens der Spiele auf den Markt. Genauer gesagt, da die Texturen bislang sowieso höchsten 16-bittig waren, blieb der entscheidene Vorteil aus. Mir ist nicht bekannt, dass damals Programmierer das 32-Bit-Rendering forderten. Heute jedoch wird eine grössere Genauigkeit verlangt - das sollte zu denken geben.

Selbst die bemängelte Voodoo3 mit ihrer 16-Bit-Grafik hat natürlich eine 32-Bit-Pipeline. Lediglich die Schreib/Lese-Zugriffe auf den Framebuffer sind 16-bittig. Der Farbwert muss dazu stark gerundet werden. Zusätzlich kommt ein Raster-Verfahren zum Einsatz, um die Farbrandbildung zu reduzieren. Beim 32-Bit-Rendering wäre ein Raster auch nicht verkehrt, ist bislang jedoch nicht implementiert worden.

Bedeutet 64-Bit-Rendering nun jedoch gleichzeitig 64 Bit Farbe? Natürlich nicht, 32-Bit-Rendering erzeugt zum Beispiel 24 Bit Farbe, da hier volle 8 Bit für den Alpha-Kanal (Transparenz) reserviert sind. Beim 64-Bit-Rendering werden vermutlich 16 Bits pro Kanal verwendet, so dass sich die Anzahl der sichtbaren Farben von ca. 16,7 Mio. "nur" auf 281,4 Mrd. erhöht (und nicht auf 18,4 Mrd. Mrd.).

Der Punkt ist: Nach einer Blend-Operation (Vermischen zweier Farben bzw. ganzer Texturen) kann das Ergebnis bislang nur mit einer Genauigkeit von 8 Bit pro Kanal (Rot, Grün, Blau, Alpha) in den Framebuffer geschrieben werden. Der durchschnittliche Rundungsfehler nach einer Blend-Operation beträgt dann knapp 0,2 %. Bei 11 Texturen (und damit 10 Blend-Operationen) wären das bereits fast 2 %. Das liegt natürlich dann schon im sichtbaren Bereich.

Obwohl 32-Bit-Rendering schon recht gute Ergebnisse liefert, ist es offenbar nicht der Weisheit letzter Schluss. Sowohl OpenGL als auch DirectX sehen pro Dreieck bis zu 8 Texturen vor. Kyro und Rampage können bis zu 8 Texturen sogar in einem "Pass" (Rendering-Durchgang) auftragen, so dass man dabei nicht nur Framebufferzugriffe spart - sondern auch die dabei auftretenden Rundungsfehler umgeht! Der Geforce3 erlaubt immerhin 4 Texturen, die anderen Chips in der Regel 2 Texturen pro Pass, die Radeon-Serie immerhin 3 Texturen. Reichen 8 Texturen dem Programmierer nicht aus, kopiert er halt die Dreiecke, um weitere Texturen aufzutragen. So bekommt man schon heute 4 oder mehr Texturen auf "ein" Dreieck.

John Carmack wünscht sich nun aber bis zu 20 Texturen pro Pixel! Und wozu braucht er die? Da sollte man mal besser den Meister selber fragen :-). Ich kann mir vorstellen, eine Grundfarben-Textur, Material-Textur, Detail-Textur 1, Detail-Textur 2, Lightmap, Shadowmap, Enviromentmap und Bump-Map zu verwenden. Das wären trotz dezenter Übertreibung nur schlappe 8 Stück. Zumal Bumpmapping in Zukunft hoffentlich durch das deutlich schönere Displacement Mapping ersetzt werden wird.

Ich vermute daher, dass Carmack andere Dinge vor hat: Beim Einsatz von 8 farbigen Lichtquellen kann man kein Hardware-T&L mehr verwenden, denn keine für den Privatanwender erschwingliche Hardware bekommt das für "real world"-Umgebungen in Echtzeit gerendert. Die heutigen T&L Engines können zwar Lichtberechnungen in Hardware durchführen, stoßen dabei allerdings schon bei sehr wenigen Lichtern an ihre Limits, so daß diese Technik bisher nur in einzelnen Fällen benutzt wurde. Vielleicht erwägt Carmack, einfach 8 - oder sogar noch mehr - Lightmaps einzusetzen. Das ist sehr CPU-aufwändig, aber bei der momentanen CPU-Entwicklung vermutlich spätestens Mitte 2002 mit jedem ALDI-PC machbar. Vielleicht möchte er dies auch mit Shadowmaps kombinieren. Und vermutlich hat er genauso noch vor, mehr Transparenz zu verwenden, was ebenfalls die Zahl der Blend-Operationen erhöht.

Kurz: So viele Textur-Schichten für einen Pixel machen durchaus Sinn. Eine Grafikkarte mit 32-Bit-Rendering und -Framebuffer würde hier unansehliche Ergebnisse liefern. In der Tat sehen heutige Grafiken nicht gerade lebendig aus. Ob nun eine Steinwand, eine Tapete oder glänzendes Metall: Die Grafik ist zwar heute zwar schon viel schöner aus als vor 2 Jahren, kommt aber noch längst nicht an Fotorealismus heran.