3D-Engine Ogre

Moderne Computerspiele zaubern atemberaubende Bilder auf den Bildschirm. Die Hauptarbeit verrichtet dabei die so genannte Engine. In der Regel kümmert sie sich um eine möglichst schnelle Berechnung der Szene, abstrahiert von der zugrunde liegenden Hardware und erleichtert so den Programmierern das Leben. Die Entwicklung einer Engine erfordert viele Mannjahre Arbeit, was sich letztlich auch im Preis widerspiegelt. Das aktuelle Programmgerüst des Actionspiels Unreal Tournament ist beispielsweise ab 350000 Dollar zu haben und somit für Endkunden oder kleinere Unternehmen schlichtweg unbezahlbar - an die Entwicklung freier Spiele damit ist gar nicht zu denken.

Mittlerweile gibt es jedoch zahlreiche freie Engines unterschiedlichster Ausprägung. Eine von ihnen ist Ogre (Object-Oriented Graphics Rendering Engine), die Dank LGPL-Lizenz sogar kommerzielle Projekte verwenden dürfen [1]. Gegenüber anderen freien Engines punktet Ogre unter anderem mit der Unterstützung von Shader-Programmen, mit einem Partikelsystem und einem modularen Aufbau über Plugins.

Obwohl Ogre hauptsächlich Spiele antreibt, ist die Engine recht universell ausgelegt. Sie ist daher auch für andere Projekte im 3D-Echtzeitbereich bestens geeignet. Das derzeit wohl bekannteste Anwendungsbeispiel ist das kommerzielle Adventurespiel Ankh [2].

Spezialgebiet: Grafik

Ogre versteht sich vorwiegend als Grafik-Engine. Andere Aufgaben, zum Beispiel die Ausgabe von Tönen, müssen zusätzliche Softwarekomponenten übernehmen. Einen Überblick über die Architektur gibt Abbildung 1. Zum Ausgleich läuft die 3D-Engine plattformübergreifend unter Windows, Mac OS X und Linux. Tipps zur Übersetzung der Engine gibt der Kasten "Installation".

Beim Entwurf von Ogre achteten die Entwickler nicht nur auf konsequente Objektorientierung, sondern auch auf möglichst einfache Benutzbarkeit. Wie das in diesem Artikel entwickelte Beispiel zeigt, genügen bereits wenige Zeilen Quellcode, um einen Roboter auf den Schirm zu zaubern. Diese Schlichtheit erleichtert nicht nur den Einstieg, das System qualifiziert sich damit auch für Prototyping-Aufgaben.

Leider ist Ogre etwas wählerisch bei den Programmiersprachen. So wurde die 3D-Engine vollständig in und für C++ geschrieben. Weitere Bindungen existieren derzeit nur für Python und Lua. Eine Umsetzung für Java steckt noch in den Kinderschuhen [3].

Einblick in die Arbeitsweisen von Ogre erhält man am besten anhand eines kleinen Beispiels. Ziel soll im Folgenden die Darstellung des bereits angesprochenen Roboters sein. Voraussetzung sind C++-Kenntnisse sowie grundlegendes Wissen über 3D-Grafiken. Hilfreich, aber nicht zwingend ist die Beherrschung von Entwurfsmustern (Design Patterns). Ogre setzt häufig Singletons (es gibt in der Anwendung nur ein Objekt einer Klasse) und Listener (ein Objekt wird von einem anderen benachrichtigt) ein.

Ausgangspunkt für die Ogre-Programmierung ist Listing 1. Die Datei »beispiel.cpp« lässt sich am einfachsten per

gcc -o beispiel `pkg-config --cflags OGRE` `pkg-config --libs OGRE` beispiel.cpp

übersetzen. Damit entfällt die Sorge um Flags und einzubindende Pfade. Viel kann das Programm jetzt allerdings noch nicht. Der leere »try«-Block nimmt später die eigentliche Funktionalität auf. Wenn dort etwas schief läuft, gibt Ogre eine Ausnahme-Warnung aus. Der anschließende »catch«-Block fängt sie ein und bemüht zunächst den »PlatformManager«. Dieser kapselt alle plattformabhängigen Dienste, beispielsweise das in diesem Fall angeforderte Dialogfenster für Fehlermeldungen. Anschließend visualisiert »display()« die mit der Ausnahme übermittelte Fehlermeldung. Unter Linux entspricht dies in der Regel einer Textausgabe auf der Kommandozeile.

Abbildung 1: Unter Linux benutzt Ogre die OpenGL-Bibliothek: Eine Anwendung ruft eine Ogre-Funktion auf, die das gewünschte Verhalten in OpenGL-Anweisungen umsetzt. Diese werden an die gleichnamige Bibliothek weitergeleitet, die wiederum mit der Grafikkarte kommuniziert. Den Sound übernimmt SDL.

Um keine Verwirrung zu stiften, stecken übrigens alle Ogre-Klassen im Namespace »Ogre«. Da es in diesem Beispiel keine Doppeldeutigkeiten gibt, befreit die dritte Zeile von der ansonsten geltenden Präfixpflicht.

Die erste Aufgabe auf dem Weg zu einer eigenen Ogre-Anwendung besteht darin, ein Root-Objekt anzulegen:

Root* myroot = new Root("plugins.cfg", "ogre.cfg","ogre.log");

Dieses Root-Objekt ist das Kernobjekt in Ogre und somit der Einstiegspunkt für alle weiteren Aktivitäten. Von ihm darf immer nur ein Objekt pro Anwendung existieren, das man zudem immer erst am Ende des Programms zerstören sollte.

Abbildung 2: Das grundlegende Objekt der Ogre-Engine ist Root. Es kontrolliert den Szenen-Manager und das Render Window.

Das Root-Objekt erwartet bei seiner Erzeugung die Übergabe von drei Dateinamen. In »plugins.cfg« sind alle Pfade zu den Plugins abgelegt, die die künftige Anwendung benötigt. Standardmäßig sieht sie aus wie in Listing 2. Dank dieses Konzepts lädt Ogre keine unnötigen oder unpassenden Funktionen. Die nächste Datei »ogre.cfg« enthält alle übrigen Konfigurationsdaten, beispielsweise die zu verwendende Fenstergröße. Sämtliche Texte, die Ogre auf der Konsole ausgibt, finden zusätzlich ihren Weg in eine Logdatei. Ihren Namen gibt der dritte Parameter an. Nur die Datei »plugins.cfg« muss beim Programmstart bereits existieren.

Fensterln

Als Nächstes ist ein Fenster einzurichten, das den Roboter anzeigt. Das erledigt etwa der folgende Zweizeiler:

if(!myroot->restoreConfig()) if (!myroot->showConfigDialog()) return 1;
RenderWindow* mywindow = myroot->initialise(true,"LinuxMagazin Beispiel");

Er versucht zunächst eine bestehende Konfiguration aus der Datei »ogre.cfg« zu lesen. Falls die nicht existiert, zeigt das Programm einen Konfigurationsdialog an. Alle dort vorgenommenen Einstellungen wandern in eine neue »ogre.cfg«, die schließlich die alte ersetzt. Auf diese Weise merkt sich die Anwendung ihre letzten Einstellungen.

Die zweite Zeile erzeugt ein neues Fenster, das sofort angezeigt wird (»true«), den Titel »LinuxMagazin Beispiel« trägt und auf den zuvor eingelesenen Konfigurationsdaten basiert. Das Ausgabefenster sollte immer zu einem möglichst frühen Zeitpunkt entstehen, da Ogre beziehungsweise die darunter liegende SDL sonst leicht einmal abstürzt.