Collision Trees

Die einzelnen Stufen der Kollisionserkennung

Visualierung des Sphere-trees anhand eines Beispiels: Bei diesem Modell wurden 6 Ebenen erstellt.

 

In Rahmen der Entwicklung der Spherical-Engine habe ich eine Lösung für objektunabhängige Kollisionserkennung entwickelt. Die Anforderung war, beliebige 3D Objekte zu laden und beim Ladevorgang mit Kollisionserkennung auszustatten.

Neben verschiedenen Ansätzen, entschieden David Kronenberger und ich uns dazu, die Objekte durch Kugeln zu approximieren, da dann die Auflösung der Kollisionen recht einfach ist. Um Rechenaufwand zu sparen und die Objekte möglichst genau zu approximieren, verwenden wir einen Sphere-Tree und testen erst auf der gröbsten Ebene, ob die Objekte überhaupt kollidieren können. Dann wird mit der nächsten Ebene fortgefahren bis entschieden werden kann, dass die Objekte kollidieren. Beim Laden der Objekte kann dabei angegeben werden, wie viele Ebenen für die Kollision erstellt werden sollen. In der Demo dazu, wurden die Kugeln visualisiert um die Korrektheit der Kollisionsüberprüfung zu testen. Der Sphere-tree wird bisher nur auf basis von Octrees erstellt. Dies ist zwar keine optimale Lösung, aber sie ist einfach und vor allem schnell.

Erste Demo der „Spherical Engine“

Seit nun mehr als 3 Jahren entwickeln David Kronenberger und ich in unserer Freizeit an einer Spiele-Engine, mit der wir unseren Traum von einem eigenen Spiel verwirklichen wollen.

Die Grundlage der Engine ist fertig gestellt und ermöglicht eine einfach Verwaltung von einer großen Anzahl an Objekten in einer 3D-Szene. Mit verschiedene Techniken werden detaillierte Objekte nur in der Nähe angezeigt wohingegen grobe und große Objekte noch in weiter ferne erkennbar sind. Darüber hinaus gibt es die Möglichkeit, ein Objekt in den Hintergrund zu setzen, wie hier in dem Screenshot der Nachthimmel.

Die Game-Engine ist in Java geschrieben und verwendet die LWJGL-API für das Rendern mittels OpenGL. Nach dem Start mit OpenGL 1.0 basiert die Engine heute auf OpenGL 3.1 und ist auch nicht mehr abwärtskompatibel. Diese Entscheidung beruhte darauf, dass heute (so gut wie) jeder Computer mindestens OpenGL 3.3 unterstützt und dass mit der Version 3.1 einige Funktionen „deprecated“ wurden, so zum Beispiel die Funktionen der Fixed-Pipeline. Entsprechend muss alles mit Shadern implementiert werden.

Diese erste Beispielszene verifiziert die Funktionsweise der Transformation der Objekte, sowie deren Abhängigkeiten und kann hier als *.jar runtergeladen werden. Die Objekte werden in Bäumen gespeichert und die Kindknoten bewegen sich mit ihren Elternknoten mit. Gleichzeitig sind die Koordinaten der Kindknoten abhängig vom globalen Koordinatensystem und nicht vom Koordinatensystem der Elternknoten.

Programmier-AG

Screenshots der Spiele aus der Java-AG

Screenshots der Spiele aus der Java-AG

Die Java-AG war eine von mir ins Leben gerufene AG am Wiprech-Gymnasium in Groitzsch, in der ich mit einigen Mitschülern Spiele programmiert habe. Hier haben wir innerhalb der letzten zwei Jahren, neben unserem Abitur einige spiele programmiert.

Die Spiele wurden in Java programmiert. Als Grafikschnittstelle wurde das von Java2D bereitgestellte Canvas verwendet.

Die Java-AG sollte dazu dienen, neben dem Informatikunterricht eine Programmiersprache zu vertiefen. Gleichzeitig wollten auch alle Teilnehmer lernen, wie man Spiele entwickelt.