|
|
 |
| Aus dem Leben eines Grafik Programmierers |
|
 |
|
|
[Tech Tagebuch] Aus dem Leben eines Grafik Programmierers
von Sebastiano Mandala
Endlich nach über einem Jahr, habe ich die Gelegenheit, zu beweisen, dass ich auch in diesem Projekt existiere! Keine einzige Zeile in den Credits, kein Bild irgendwo von dem armen einzigen aktiven Italiener im Projekt. Also, hier bin ich Sebastiano Mandala, Grafik-Coder für The Chronicles of Spellborn.
Für diesen Eintrag wurde mir vorgeschlagen, dass ich über Kaffee und das Wetter sprechen sollte, weil Pizza und Mandolino viel zu klischeehaft wären. Ich habe mich schließlich entschlossen, über meine Arbeit hier zu schreiben, auch wenn mein Sizilianisches Englisch hinterher von jemandem korrigiert (Anm. d. Übers.: und dann auch noch übersetzt) wird, bevor ihr das zu Augen bekommt.
Hauptsächlich ist meine Mission hier, dafür zu sorgen, dass ihr das Spiel mit einer akzeptablen Framerate spielen könnt..
Als ich angeheuert wurde, erzählten mir die jubelnden Leute hier im Büro, dass sie mit einer nicht ganz neuen 3D-Engine arbeiten, die nur für Indoor-Games benutzt wird, die nicht mehr als 8 Spieler haben oder sowas. Ich dachte, der arme Kerl, der sich darum kümmern muss, dass ein Spiel mit großen Außenleveln in einer MMO-Umgebung auf einer solchen Engine läuft. Nun, der arme Kerl bin ich jetzt.
Sagen wir mal, dass es mit der Unreal Engine, so wie sie ursprünglich gedacht war, völlig unmöglich gewesen wäre, unser Spiel vernünftig zu rendern. Zumindest auf der Maschine die ich hier benutze (das ist ein Dual Core, mit einer Geforce 6800), hätte das nicht mehr als 10 fps gebracht.
Als ich mit der Arbeit anfing, war die Engine schon stark modifiziert, um eine Menge Features einzubauen, die für das Design nötig waren, aber an der Optimierung war fast nichts gemacht worden.
Natürlich liegt das Endergebnis nicht nur an den heldenhaften Anstrengungen, die wir unternommen haben um den Code schneller und geeigneter für diese Art MMO-Spiel zu machen, sondern auch an der unglaublichen Arbeit unserer Leveldesigner, die mit jeder Menge Beschränkungen arbeiten müssen. Der Unreal Editor ist eigentlich ein gutes Tool, aber wir haben ihn sehr in die Mangel genommen. Denkt mal an Unreal. Das basiert stark auf BSP (wie ihr ja alle wisst), aber wir benutzen die BSP-Struktur in unserem tollen Spiel fast gar nicht.
Also, wie machen wir das dann spielbar?
Nun ja, zum einen haben wir eine ganze Menge Optimierungen vorgenommen und es gibt natürlich noch eine ganze Menge, was wir noch weiter verbessern können, aber alles fängt damit an, dass die GPU die CPU besser kennen lernt und die beiden sich ineinander "verlieben". Auf Deutsch (also ohne Mandolinen-Ballade) bedeutet das, dass GPU und CPU parallel arbeiten müssen.
Ich werde euch mal ein paar Beispiele geben, damit ihr euch das vorstellen könnt.
In den letzten paar Jahren war "Batching" das Zauberwort, um 3D-Engines GPU-freundlicher zu machen. Vorher war die übliche Methode zu "batchen" einer Szene, so viele Texturen wie möglich in eine große Textur zu packen, die nicht größer war als 1024x1024. So konnte man so viele Polygone in einem Aufruf rendern wie es geht und dabei nur eine einzige gepackte Textur benutzen! Das ist gut für die geplagte GPU.
Aber, was ist wenn das Spiel 1024x1024 Texturen benutzt um nur den Holzrahmen eines Fensters zu rendern?
Ganz einfach, wir mussten uns hinsetzen und eine andere Lösung finden. Da wir keine Genies sind wie Carmack, haben wir es nicht geschafft, die berühmte Me-Me-MegaTextur zu erfinden, aber wir waren gut genug, um ein System zu implementieren, das so cool klingt wie: "Dynamic Run-Time Chained Batching System".
Ich werde hier natürlich nicht erklären, was das genau ist. Nicht weil es so geheim ist, sondern weil es so langweilig ist, und ich möchte den bisher erreichten "Wow"-Effekt nicht schmälern!
Ein anderes cooles Feature, ohne das moderne Engines nicht auskommen können, ist "Asynchronous Texture Loading". Das hilft nicht nur beim ausbalancieren der Ladezyklen, sondern ergibt den Effekt, dass alle Texturen aufpoppen, während man läuft (okay, das ist ein Nebeneffekt aber ein cooler).
Also, habe ich nur an Optimierung gearbeitet, fragt ihr jetzt? Größtenteils ja, noch viel mehr als ich hier erklärt habe (und meine To-Do-Liste ist immer noch soooo lang), aber ich habe auch an einigen visuellen Effekten gearbeitet (die ganz sicher in den neuen internen Releases immer noch weiter verbessert wurden), so wie der wunderschöne bikubisch interpolierte Nebel (ein einfacher Trick, der den Eindruck ergibt, dass größere Objekte aus dem Nebel herauspoppen) und dem Anti-Aliased Rendering (ja, in zukünftigen Versionen kann man AA aktivieren!).
Vielen Dank fürs Zuhören und arrivederci alla prossima!