You are on page 1of 9

Spaceinvader 3D

CGE Projekt Christoph Ulrich s730022

Ziel

Ziel des CGE Projekts ist es eine prototypische Implementierung einer 3d-Anwendung mit Hilfe der Horde3D Rendering Engine zu realisieren.

ProjektIdee

Fr die Umsetzung des CGE-Projekts wurde das Thema Spaceinvader 3D gewhlt. Hierbei sollte versucht werden das bekannte Spielprinzip von Spaceinvader in die dritte Dimension zu transportieren und gegebenenfalls anzupassen.

Umsetzung

3.1

Verwendete Frameworks

Vorgabe fr die Umsetzung des Projekts war die Verwendung der Horde3D Rendering Engine. Zur Umsetzung des Projekts wurde der .NET-Wrapper der Horde3D Rendering Engine genutzt, der es ermglicht die Programmiersprache C# zur Implementierung zu verwenden. Zustzlich wurde die Vecmath-Bibliothek von Stefan Maierhofer (http://sourceforge.net/project/memberlist.php? group_id=92070) genutzt.

3.2

Tools und Assets

Horde3D bietet die Mglichkeit Modelle (Meshes) zu laden und diese dann programmatisch und auch deklarativ (via xml DSL) zu manipulieren. Allerdings mssen die Geometrien jedoch zuvor in die Horde3D eigene Datenreprsentation umgewandelt werden. Dies geschieht mit Hilfe des Collada Converters, der ebenfalls mit der Engine ausgeliefert wird. Allerdings mssen dafr die Geometrien und Modelle im Collada-Format vorliegen. Die meisten 3D-Authoring Anwendungen verfgen nicht ber einen Exporter fr das ColladaFormat. Fr 3Ds Max und Maya (die gngigsten und professionellen 3D Authoring Tools) kann ein Collada Exporter Plugin installiert werden, welches den Export im Collada-Format ermglicht. Der Export der Modelle fr dieses Projekt aus 3DS Max wurde mit den OpenCOLLADA Tools

vorgenommen. Hiermit konnten die Modelle unkompliziert und zuverlssig exportiert werden. Ein Vorteil dieser Tools war es, das die Modelle auf 1 Unit skaliert werden konnten, was die weitere Handhabung der Modelle in der Horde3D Engine stark erleichterten. Die Tools knnen unter http://www.opencollada.org/download.html heruntergeladen werden. Fr das erstellen von Cubemaps wurde zuerst versucht den NVidia's DDS Exporter for Photoshop zu verwenden, dies stellte sich jedoch als unpraktisch und langwierig heraus (zumal man auch Photoshop installiert haben muss). Daher wurden die Cubemaps dann mit Hilfe von ATI CubeMapGen generiert, das sich als besser und schneller nutzbares Tool prsentierte. Ein kurze Einfhrung zur Nutzung der beiden Werkzeuge, und die Adressen wo die Software zum Download Angeboten wird lassen sich unter http://www.cgtextures.com/content.php? action=tutorial&name=cubemaps finden. Zur Erstellung der Texturen wurde eine (fr Studenten freie) Version von CrazyBump (http://www.crazybump.com/) verwendet. Mit CrazyBumb lassen sich unter anderem aus Texturen (Bildern) Normal-, Specular-, Displacement-, Occlusion- und Diffuse generieren und manipulieren. Fr das Projekt wurden aus Zeitmangel nur die Diffuse- und Normal-Maps verwendet. Als Assets wurden Gegener, das Spieler-Raumschiff, ein Zylinder mit Deckel (Laser), Wrfel (Hochhausbauteil) und eine Ebene als Bodenplatte neben den im Chicago - Beispiel enthalten Assets verwendet. Es wurden noch mehr Assets erstellt, die ebenfalls aus Zeitmangel nicht mehr in das Projekt mit einflieen konnten.

Abbildung 1: Gegner in 3DS Max mit Texturen

3.3

Implementierung

Als Grundlage fr die Implementierung wurde das sample Chicago Beispielprojekt verwendet, welches mit der Engine (und auch mit dem .NET-Wrapper) ausgeliefert wird. Dieses Beispielprojekt wurde sukzessive verndert und erweitert. Abbildung 2 stellt einen Screenshot vom Endergebnis dar und visualisiert die wichtigsten Entities des Spiels : 1. Das Raumschiff (Player), welches vom Spieler mit den Pfeiltasten gesteuert wird 2. Die Gegner (Enemy) die selbst einer Gruppe, der EnemyGroup organisiert werden 3. Die Stadt (b.z.w. der Huserblock CityBlock), die die Umgebung bildet. Im folgenden wird auf diese Entities genauer eingegangen und ihre Eigenschaften und Funktionalitt grob erlutert.

Abbildung 2: Screenshot Sturzflug auf die Stadt zu

3.3.1

Entities und der EntityManger

Um den H3DNodes zustzliches Verhalten hinzufgen (wie z.B. Bewegung) zu knnen ohne diese direkt zu verndern und dies auf eine objektorientierte Weise zu tun wurde eine Klasse Entity implementiert. Diese kapselt das zustzliche Verhalten, berechnet bei Aufruf seiner update -Methode den neuen Zustand einer Entity und delegiert die Umsetzung der Zustandsnderungen an die Horde3D API. Eine Entity kennt jeweils den H3DNode, fr den sie zustndig ist. Entities knnen Baumstrukturen bilden. Hierbei kennt eine Entity seinen parent und seine children. Die Objekte der Entity Klasse bildet die Basis fr alle Elemente des Projekts die zustzliches Verhalten haben sollen. Entities knnen mit dem entsprechenden Konstruktor Horde3D Resourcen automatisch laden. Der EntityManger ist ein als Singleton implementierte Hilfsklasse, die den eien Art Wurzelknoten darstellt. Jedes Entity das sein Verhalten whrend des Renderns ndern soll ist direkt oder indirekt beim EntityManager angemeldet. Er ruft vor jedem Rendern der Szene die update-Methoden aller bei ihm angemeldeten Objekte auf, die von der Entity Klasse ableiten.
3.3.2 Das Raumschiff

Die Player-Klasse ist einen Gruppenknoten dem das Raumschiff, die Triebwerke und der Laser untergeordnet sind. Die Triebwerke sind mit Hilfe von Horde3D Partikelsystemen umgesetzt. Um den Triebwerken einen eigene Charakter zu geben wurden fr die Billboards der Partikel eine eigene Textur angefertigt. Das Raumschiff nutzt den leicht angepassten model shader aus dem Chicago Beispiel. Die mit Cubemap-Textur wir hierbei mit der Diffusen Textur des Raumgleiters gemischt. Da diese relativ dunkel ist setzt sich bei der Addition der beiden Textur Samples das Cubemap strker durch. Durch das Normal-Map und die dadurch beeinflusste Reflexion der Umgebung erscheint die Geometrie des Raumschiffs noch detaillierter. Der Laser ist eine Zylindergeometrie mit Deckeln. Der Laser Shader sorgt dafr, das jedes Fragment in rot gerendert wird. Beim abfeuern des Lasers wird dieser aus dem Raumschiffgruppenknoten ausgehangen und in H3DRootNode eingehangen. Dies geschieht damit der Laser autonom vom Gruppenknoten des Raumschiffs in den absoluten Koordinaten transformiert werden kann. Dazu muss die Transformationsmatrix des Gruppenknoten auf den Laser angewendet werden, damit er seine ursprngliche Positionierung beibehlt. Ist dies alles geschehen wird der Laser sichtbar (aktiv) gemacht und wird auf seiner lokalen Z-Achse verschoben. Um zu prfen ob der Laser auf seinem Weg einen Gegner trifft, wird ein Strahl (h3d.castRay) in Schussrichtung geschickt. Die Lnge und Richtung des Strahls wird durch die momentane und die vorherige Position bestimmt. Falls der Strahl ein potentielles Ziel trifft wird dieses mit Hilfe von h3d.getCastRayResult identifiziert. In der aktuellen Version des .NET-Wrappers fr Horde3D sind die Parameter nicht korrekt, diese gilt es selbst im .NET-Wrapper zu korrigieren. Tut man dies nicht wird man keine Ergebnisknoten erhalten. Der int node parameter muss zu out int node gendert werden damit man eine Referenz auf den getroffenen Knoten erhlt. Wird also der Knoten der getroffen wurde identifiziert, wird dieser dem EnemyGroup-Objekt mitgeteilt, das sich dann darum kmmert den getroffene Gegner ber dieses Schicksal mit Hilfe seiner hit-Methode informiert. Allerdings muss festgestellt werden, das die momentane Berechnung des Strahls zu fehlerhaften Ergebnissen fhrt. Vermutlich ist der Abstand zwischen den beiden Punkten, die die Richtung des Strahls bestimmen, zu gering. Die Richtung des entsandten Strahls ist dadurch sehr ungenau. Dieses Problem knnte behoben werden indem man den Laser und einen Hilfsknoten in einen Gruppenknoten einhngt. Diese Gruppe wrde dann als Laser genutzt werden und die Position des Hilfsknotens knnte dann genauer die Lnge und die Richtung des entsandten Strahls bestimmen. Zwar sollte fr den Laser ein effektvollerer Shader verwendet werden, der auch unter Rendermonkey schon entwickelt wurde, jedoch fehlte leider die Zeit diesen Shader in die Horde3D

Architektur zu integrieren. Das Raumschiff wird durch die Pfeiltasten gesteuert. Die L-Taste ist fr die Beschleunigung zustndig, die K-Taste fr das Bremsen. Mit der F-Taste wird der Laser abgefeuert. Mit der Space Taste kann das Spiel gestoppt werden.

3.3.3

Die Gegner

Abbildung 3: Die Verschiedenen Zustnde getroffener Gegner

Die Gegner sind in einer Gruppe organisiert. Diese trgt dafr Sorge das aus der Anzahl der hinzugefgten Gegner-Resourcen, der Angabe der Anzahl der Gegner pro Reihe in der Tiefe und in der Breite eine Gegnerformation erstellt wird. Der Abstand der Gegner Unter einander kann ber das Feld density gesteuert werden. Beim Positionieren der einzelnen Gegner wird ein durch Zufall bestimmter Offset auf die Position der Gegner angewendet. Dies soll die Gruppe etwas organisch angeordneter wirken lassen. Trifft ein Laser einen Knoten wird das EnemyGroup Objekt ber die hitNode-Methode darber informiert. Es erhlt hierbei als Parameter die H3DNode id des getroffenen Knotens. Anhand dieser wird der Gegner ermittelt der getroffen wurde und dessen Feld lifePower ber die hit-Methode herabgesetzt. Ist die lifePower zwei ist der Gegner noch nicht getroffen, ist sie 1 wurde der Gegner bereits einmal getroffen und fliegt nun desorientiert in seiner Gruppe herum. Ist die lifePower

kleiner oder gleich der Zahl Null strzt der getroffenen Gegner ab oder flchtet zurck gen Atmosphre zu seinem Heimatplaneten. Beim ersten Treffen gibt es eine grne Explosion die mit einem Partikelsystem realisiert ist. Nach der Explosion ist der Gegner angeschlagen und leckt grnes Plasma, welches ebenfalls mit einem Partikelsystem realisiert ist. Auch fr die Gegner ist ein Shader (mehrere Shaderprogramme) erstellt worden, der nicht mehr integriert werden konnte.

Abbildung 4: Screenshot des Gloweffekt Shader in Rendermonkey

3.3.4

Die Stadt

Die Stadt ist mit Hilfe der CityBlock-Klasse erstellt. Man kann Objekten dieser Klasse beliebig viele Ressourcen hinzufgen. Bei der Erstellung eines Gebudes wird zufllig ausgewhlt aus welcher Ressource das Gebude errichtet werden soll. Man kann die Dimensionen des Huserblocks bestimmen aus denen dann unter zustzlicher Verwendung von Zufallszahlen die Huser errichtet werden. Hierbei werden die Gebude zufllig um die Y-Achse Rotiert, Skaliert und Positioniert. Die Feld houseDensity bestimmt wie dicht die Huser bei einander stehen also auch

wieviele Errichtet werden. Im diesem Projekt kommt nur eine Resource zum Einsatz. Es handelt sich dabei um einen Wrfel der unterschiedliche Texturen auf drei Seiten hat. Um das Erscheinungsbild der Gebude etwas variabler zu gestalten wurden diese Wrfel die die Hausbauteile darstellen jeweils noch einmal per Zufall auf der X-, Y- oder Z-Achse um 90 Grad rotiert.