Die eierlegende Wollmilchsau

Bereits mehrfach hatte ich versucht für meine Games und für die starLiGHT.Engine ein System zu entwickeln, daß für die unterschiedlichsten Aufgaben eingesetzt werden kann. Dabei ging es mir hauptsächlich darum, daß alle sichtbaren Objekte verwaltet werden, mehrere Kameras existieren, Split-Screens möglich sind, ein Culling ermöglicht wird, daß sich möglichst optimal an die Anforderungen des Spiels anpasst, die Verwaltung von dynamischen Lichtern und Schatten, sowie eine Möglichkeit, daß Post-Processing zu unterstützen.
Um diese Aufgabe noch ein wenig zu „verfeinern“ sollten dabei möglichst flexibel Shader und unterschiedliche Materialien auf einzelne Objekte wirken können, Animationen und Verhalten in Objekte injiziert werden können und das Ganze sollte unabhängig davon funktionieren, ob eine 3D oder 2D-Szene vorliegt. Multi-Threading sollte natürlich auch nicht verhindert werden, sondern eher unterstützt werden.
Eine klassische „Eierlegende Wollmilchsau“ also.

Seit ich vor einigen Jahren die ersten Versuche mit der starLiGHT.Engine gemacht habe, damals noch mit C++ und einem Render-System, daß sowohl mit DirectX, als auch mit OpenGL funktionierte habe ich immer wieder versucht, dieses Ziel zu erreichen. Immer wieder habe ich neue Ansätze ausprobiert und Pakete geschnürt, die dem System aus meinen Vorstellungen möglichst nahe kommen sollten. Ungefähr 10 mal habe ich dies gemacht und immer wieder habe ich die Ansätze verworfen und irgendwann nicht weiter verfolgt. Trotzdem hatte dies jedes mal seinen Sinn und ich wurde jedes mal um ein wenig Erfahrung reicher.

Die Arbeit war also nicht sinnlos. Das häufige Verwerfen des gesamten Systems und ein Neuanfang waren sogar außerordentlich positiv, da ich so alle alten Zöpfe abschneiden konnte und jedesmal bei Null anfangen konnte. Wirklich bei Null? Nein, eigentlich nicht, denn die Erfahrung war ja da und ist jedesmal ein wenig mehr eingeflossen und hat dazu geführt, daß ich der Lösung immer näher gekommen bin.

Mittlerweile habe ich einen weiteren, kleinen Erfolg geschafft und vielleicht habe ich diesmal den Anfang des finalen Systems entwickelt. Jedenfalls habe ich nun ein recht flexibles System, daß gerade einem Härtetest unterzogen wird und in einigen meiner Prototypen für Spiele eingebaut wird.

<h2>Was kann das System?</h2>

Das ist relativ einfach mit einer kleinen Auflistung zu beschreiben:

  • Scene-Management

Ein austauschbarer SceneManager kümmert sich um die Verwaltung der SceneObjects. Dies ist eine recht abstrakte Geschichte, denn SceneObjects können alles mögliche sein und sind im Grunde genommen nur eine Ansammlung von Objekten, die unterschiedliche Dinge können. Der Scene-Manager kümmert sich dabei im Grunde nur darum, daß diese Objekte irgendwie beisammen gehalten werden und kann Hierarchien aufbauen.

  • Kamera-Management

Eine jede Kamera ist erstmal ein SceneObject und ist damit auch im SceneManager gespeichert. Alles was ein SceneObject kann, kann also auch eine Kamera. So ist es sehr einfach Konstrukte wie eine „Head-Mount-Camera“ zu erzeugen, also Kameras, die der Bewegung eines Objektes folgen. Viel wichtiger ist jedoch, daß der Kamera-Manager die Aktualisierung der Kamera-Parameter verwaltet und für die Erzeugung von Kameras zuständig ist. Auch kümmert dieser sich darum, daß spezielle Verhalten von Kameras zu verwalten.

  • Licht-Management

Auch ein Licht ist, genau wie eine Kamera von einem SceneObject abgeleitet. Scheinwerfer können so ganz einfach an das Chassis eines Autos montiert werden und folgen so automatisch jeder Bewegung. Trotzdem gibt es noch einiges für das Licht-Management zu tun: Es müssen unterschiedliche Licht-Typen erzeugt werden und in Abhängigkeit vom Typ ist die Sichtbarkeit zu regeln. Einige Renderer, zu denen wir später noch kommen werden, haben auch spezielle Anforderungen an die einzelnen Lichter und müssen unterschiedlich auf diese Datenstruktur zugreifen bzw. sind in der Lage bestimmte Dinge zu optimieren (dynamische und statische Lichter etc.).

  • Schatten-Management

Schatten gibt es nur, wenn es auch Licht gibt und daher arbeitet der Schatten-Manager auch sehr eng mit dem Licht-Management zusammen. Der Schatten-Manager ist jedenfalls dafür zuständig, daß Schattenvolumen aufgebaut werden oder aber auch spezielle Projektionsmatrizen erzeugt werden, um einen Schattenwurf zu simulieren. Er soll natürlich ebenfalls sehr flexibel sein und mit den unterschiedlichsten Algorithmen zusammenarbeiten, so daß dynamische, statisch, zweidimensionale und dreidimensionale, harte und weiche Schatten möglich werden.

  • Render-System

Das Render-System kümmert sich darum, daß etwas sichtbares auf den Bildschirm gelangt und steuert alles, was damit zu tun hat. Dies ist keine einfache Schleife, sondern das Render-System ermittelt mit allen anderen Teilen und Managern, welche Objekte sichtbar sind, welche räumlichen Abhängigkeiten bestehen, welche Schatten erzeugt werden müssen, was wo dargestellt wird und vieles mehr. Das Render-System ist nicht auf einen einzelnen Pass oder ein einzelnes Material beschränkt, sondern hat die Möglichkeit, alles über den Haufen zu werfen und so zu rendern, wie es notwendig ist. Dies ist wichtig, um Algorithmen wie Forward Rendering, Multipass Rendering, Light Pre Pass oder Deferred Shading zu ermöglichen.

  • Core

Der Core ist die Klammer, die alles zusammen hält. Es ist ein Manager, der die anderen Manager zusammenhält und für deren Instanziierung zuständig ist. Es wird ein einfaches Interface geboten, daß es dem Entwickler erleichtert, mit dem komplexen Gesamtsystem zu arbeiten, ohne exakte Details der Internas kennen zu müssen.

Wie geht’s weiter?

Ich habe in den letzten Tagen bereits einige Interfaces und teilweise sogar abstrakte Klassen in das Repository der starLiGHT.Engine eingecheckt, die die Basis dieses Systems bilden. Der aktuelle Stand ist jedenfalls, daß ich folgendes machen konnte:

  • 2D-Szene gegen 3D-Szene austauschen
  • Forward Rendering, Deferred Shading und Light Pre Pass transparent austauschen
  • Bestehende Projekte schnell und einfach auf das neue System umstellen

Fazit

Mit diesem Artikel wollte ich ein wenig verdeutlichen, daß eine evolutionäre Entwicklung von Systemen nicht unbedingt immer schlecht sein muß. Diese Art der Entwicklung kostet zwar sehr viel Zeit und Mühe, ist aber gut geeignet zum lernen von neuen Techniken und Ansätzen.

Advertisements

Veröffentlicht am 11.03.2011 in Post-Mortem, Random Noise und mit , , , , , , , getaggt. Setze ein Lesezeichen auf den Permalink. Ein Kommentar.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: