Ogre unter Linux



Installation von Ogre

Mit Ogre hatte ich vor einigen Jahren schlechte Erfahrungen gemacht. Es war mir einfach nicht gelungen, die Library unter Linux zu installieren, weil Ogre zu anspruchsvoll bezüglich der sogenannten "Requirements" ist. Eine große Menge anderer Libraries und das noch in aktuellen Versionen war erforderlich. Ohne das ganze System zu aktualisieren erwies sich die Installation von Ogre schließlich als unmöglich; die unendlich vielen Abhängigkeiten waren nicht aufzulösen. Das Risiko eines System-Upgrades wollte ich natürlich nicht eingehen.

Nachdem ich nun das brandneue Ubuntu 12.04 installiert hatte, wollte ich einen neuten Installationsversuch starten, obwohl ich der monströsen Library immer noch skeptisch gegenüber stehe. Der Grund für den erneuten Versuch: Ich habe noch keine andere Library mit einer geeigneten LOD-Unterstützung gefunden. Ob Ogre das Gewünschte bieten kann, muss letztendlich ein Versuch ergeben.

Ich will gleich vorwegnehmen, dass sich Ogre auch diesmal als einigermaßen sperrig erwies, aber die Installation unter Unbuntu 12.04 hat schließlich geklappt. Man muss nur aufpassen, dass man in keine Fallstricke gerät. Als nützlich erwies sich die sehr detaillierte und umfangreiche Dokumentation, ohne die ich die Installation nicht hinbekommen hätte.

  • Die erste Frage ist, ob man Ogre mit den Ubuntu-Packages oder aus den Sourcen installieren soll. Es ist zwar verführerisch, einfach die Ubuntu-Packages zu nehmen, aber dann kann es zu Konflikten mit den Anfänger-Hilfestellungen im Ogre-Wiki kommen. Die erwarten nämlich die Libraries unter /usr/local/lib, während Ubuntu die Libraries unter /usr/lib installiert. Also am besten die Sourcen (z.B.ogre-src-v1-8-0.bz2) von der Webseite herunterladen und entpacken.
  • Bevor man den Code kompiliert, sollte man unbedingt die Prerequisites beachten und auflösen. Das geht einfach, weil die nötigen Pakete für Ubuntu aufgelistet sind. Man kann die apt-get-Anweisungen per Copy-Paste in einer Konsole übernehmen und so in in einem Rutsch bequem alles installieren und braucht auch vorher nicht nachzuschauen, ob das eine oder andere schon vorhanden ist. Ich selbst habe alles installiert, von "unbedingt erforderlich" bis "empfehlenswert".
  • Ogre setzt seit einiger Zeit auf CMake. Auch wenn man nicht gleich in die Tiefen von CMake einsteigen muss, sollte man zumindest wissen, was dieses Programm überhaupt macht. Es bemüht nicht den Compiler wie etwa Premake, sondern ist so etwas wie ein komfortables und einfach zu handhabendes Konfigurationstool, das wahlweise die Makefiles oder auf Wunsch z.B. auch Codeblocks-Projektdateien erzeugt. Um das Kompilieren muss man sich anschließend kümmern. Im Ogre-Wiki gibt es übrigens einige sehr informative und übersichtliche Anleitungen zu CMake.
  • Es ist unbedingt empfehlenswert, die grafische Variante cmake-gui zu verwenden, weil man damit besser die Optionen einstellen kann. Zwar geht das auch mit der Konsolen-Variante, aber wer kennt schon die Kommandozeilenparameter?
  • Wo man die CMake-Build-Ordner anlegt, ist egal. Ich habe sie im im Ordner der ausgepackten Ogre-Sourcen angelegt. Man kann verschiedene Builds anlegen, die Sourcen werden dabei nicht angerührt. Als Source-Ordner in CMake wird der Ordner angegeben, in welchem sich die Datei cmakelists.txt befindet.
  • Nun kann man das erste Mal in CMake die Konfiguration starten. Das meiste passt bereits, doch es empiehlt sich, die Samples zusätzlich zu markieren. Auf keinen Fall sollte man die statischen Libraries markieren, denn dann werden die unerlässlichen dynamischen Libs nicht erzeugt. Nun kann der zweite Konfigurationslauf gestartet werden, und wenn keine Fehlermeldungen kommen, wird "Generate" aufgerufen.
  • Nun wird unixtypisch kompiliert, und zwar aus dem Build-Verzeichnis heraus:

    • make
    make install

    Die Ergebnisse findet man in den Ordnern
    /usr/local/bin
    /usr/local/lib
    /usr/local/include
    /usr/local/share
  • Damit ist Ogre installiert. Man kann das alles gleich testen, indem man in einer Konsole mit "SampleBrowser" die Demo startet.

Kompilieren eines Testprogramms

Folgt man den Empfehlungen von Ogre auf der Wiki-Seite (was bleibt sonst übrig?), dann versucht man zunächst, ein Testprogramm unter Verwendung von CMake zu kompilieren. Der Vorgang ist in einem Wiki-Artikel einigermaßen nachvollziehbar beschrieben. Wenn man die Datei clean_ogre_cmake_project.zip herunterlädt, hat man bereits alles was man braucht. Als Testprogramm wird das Rahmenprogramm zu den Samples verwendet, ohne allerdings eines der Demos im Fenster anzuzeigen. Der Vorgang ist praktisch der gleiche wie bei der Installation von Ogre.

Im ersten Build sollte man einfach die Makefiles generieren lassen, die anschließend normal weiterverwendet werden. In einem weiteren Build kann man - falls gewünscht - die Codeblocks-Projektdatei oder die Projektdatei zu einer andern IDE erzeugen. Es ist also letzten Endes egal, ob man direkt über das Makefile kompiliert oder ob man diesen Vorgang einer Entwicklungsumgebung wie Codeblocks anvertraut. Im letzteren Fall müssen allerdings noch einige Dateien in den Ordner mit dem ausführbaren Programm kopiert werden. Es ist jedoch alles an etwas anderer Stelle im Dateibaum vorhanden.

Wenn das Testprogram funktioniert, hat man die Gewähr, dass Ogre richtig installiert ist und auf dem Rechner läuft - mehr aber nicht. Auf eigene Programmentwicklungen lässt sich das Testprogramm nur schwer übertragen, auch wenn bei Ogre behauptet wird, man brauche nur die Datei cmakelists.txt anzupassen. Ohne tiefgreifende Kenntnisse von CMake ist das allerdings nicht machbar. Ähnliches gilt für das generierte Codeblocks-Projekt. Hier wird eine Projektdatei erzeugt, die für normale Codeblocks-Benutzer kaum zu entziffern ist.

Ogre in eigenen Anwendungen (mit Codeblocks)

Das ist wohl der entscheidende Schritt zum Einstieg in die Programmierung mit Ogre: Ein Source-Code wird "from the scratch" in Codeblocks eingebunden. Dazu eignen sich die Testprogramme der Tutorials, z.B. der downloadbare Code der MadMarx-Tutorials. Am Beispiel des Tutorials 5 (Basic Mesh Loading) soll der Vorgang gezeigt werden:

  1. Es wird wie üblich ein neues Projekt (Konsolenanwendung) in Codeblocks angelegt. main.cpp wird aus dem Projekt entfernt und aus dem Projektordner gelöscht.
  2. Alle cpp- und h-Dateien aus dem Source-Verzeichnis des heruntergeladenen Testprogramms werden in den Projektordner von Codeblocks kopiert (es sind 5).
  3. Dasselbe geschieht mit CImg.h aus einem Unterordner. Auch diese Datei wandert in den Projektordner. Das mag irritieren, wenn bereits in /usr/local/include eine solche Datei existiert, aber die ist nicht zu gebrauchen.
  4. Schließlich wird noch der Ordner "media" in den Projektordner kopiert oder bewegt. Damit dürfte alles beisammen sein.
  5. In Codeblocks werden nun die Dateien mit <Add files recursively> in das Projekt eingebunden.
  6. In den Build options (Linker) werden zwei Libraries registriert: OgreMain und OIS.

Nun lässt sich der Code bereits kompilieren und linken, doch der Programmstart geht noch schieft. Es wird kein 3D-Fenster angezeigt, sondern stattdessen gibt es Fehlermeldungen in der Konsole. Für diese Fehler zur Laufzeit sind die nachzuladenden Plugins und sonstigen Ressourcen verantwortlich.

Die Plugins (typisch für Ogre) sind quasi dynamische Bibliotheken (Endung .so), die unter Linux üblicherweise in /usr/local/lib/OGRE untergebracht sind. In den meisten Fällen werden die Plugins über die konfigurierbare Textdatei plugins.cfg geladen, doch im MadMarx-Tutrial wird versucht, sie direkt zu laden (Zeile 93 in SimpeOgreInit.cpp). Da die Plugins nicht im Ordner mit der ausführbaren Datei liegen, muss hier der der komplette Pfad angegeben werden: mRoot->loadPlugin ("usr/local/lib/OGRE/"+lPluginName);

Ferner muss noch ein Mesh aus dem Media-Ordner geladen werden. Die Zeile 124 in main.cpp zeigt, wo dieser Order erwartet wird: ../../media/mesh. Das ist, wenn man von dem Ordner mit der ausführbaren Datei ausgeht (bin/debug oder bin/release), der Projektordner mit den Source-Dateien. Insofern stimmt der relative Pfad, wenn der Media-Ordner wie oben angegeben installiert wurde. Dass es trotzdem nicht klappt, hat einen anderen Grund. Codeblocks muss erst mal angewiesen werden, den Ordner mit der ausführbaren Ordner als Arbeitsordner zu betrachten. Dazu muss in den Projekt-Eigenschaften unter <Build targets/Execution working dir> dieser Ordner angegeben werden.

Übrigens geht das MadMarx-Tutorial auch beim Nachladen der Ressourcen nicht den üblichen Weg. Der besteht darin, alle erforderlichen Angaben in der Datei resources.cfg zu machen. Diese Datei wird dann ähnlich behandelt wie plugins.cfg.