If you like, you can follow us on Google+ – we post updates, news, concept art and more on a regular basis.

The demo was tested on Firefox 7 and 8, Opera 12 and Google Chrome 15 – each was running fine. Internet Explorer does not support WebGL – and probably never will, so you have to use another browser to see the demo…

The JSON object contains the

• vertices
• faces
• skeleton structure (bone hierarchy)
• vertexgroup definitions (weighted assignment of vertices to bones)
• animations stored in channels (can be quaternion and/or position bezier curves)

The skinning and lighting is done entirely within the vertex and fragment shaders. Just the pose matrices are calculated in JavaScript – they are then passed to the shader where the actual skinning takes place.

As you know, matrices (at least in our context of 3D graphics) represent transformations. Multiple transformation matrices can be combined using marix multiplication. But since this operation is not commutative, the order of the multiplication is important.

Since matrices represent transformations, they build new coordinate systems, too: These new systems are defined by axis vectors that have been transformed using the matrix. An example will clarify this fact:

In the examples used in this post, I will use a rotation matrix around 30 degrees, because and , which is easy to write down and we still stay exact when calculating with it.

Part 1: A single transformation matrix

Given the origin system with the axis vectors and , when we rotate these vectors around 30 degrees, we get the vectors  and

Surprisingly – or more precise: not surprisingly, the axis vectors are exactly the components of the matrix that applies the corresponding transformation!

The system axis and  are contained in the unit matrix 

The rotated axis  and  are contained in the rotation matrix: 

Not convinced that this is true? Then let us investigate what is happening when we apply the matrix transformation to a concrete point and verify the results visually:

The example point will be transformed using the identity matrix and the rotation matrix:

You see, the identity matrix keeps the same point and the rotation matrix does the correct rotation as can be seen in a graph: the point is rotated around exactly 30 degrees in mathematical positive direction and that the rotated coordinate system still contains the point with the coordinates (2,3) (shown in green):

Point coordinates stay the same when a coordinate system is rotated

Note: The coordinates always stay the same, but only the coordinate system within they are used changes.

So, for single matrices everything is clear: The matrix transforms a point and the matrix columns are the axis vectors of the system defined by the matrix. If the point is transformed, its coordinates change only seen from the origin system – within the transformed system they stay the same.

Now lets look at the concatenation of transformations.

Part 2: Concatenation of two transformation matrices

For this experiment, lets take a rotation matrix R and a translation matrix T.

We get the combined Matrix C using C=R*T. This matrix then contains both transformations: The rotation and the translation within a single matrix.

Using the combined matrix C to transform the point we get:

Rotating a coordinate system, followed by a translation

To compare this, lets transform the point with each single matrix after each other and try this with both orders:

(a) First R, then T:

(b) First T, then R:

Please note: the results we get in (b) are excatly the same as we got from the combined Matrix C above with C being R*T!

You might be surprised, but the order of transformations in (a), although this is the order in which the matrices are multiplied, does not result in the same point as the cumulated matrix C. The reason can be found when we recapture the fact, that matrix multiplications don’t change points, but coordinate systems.

So, R*T means the following: First, rotate the origin system using R – and then, within this rotated system, translate the system using T. This is the difference to the calculation of points shown in (a): There we get transformed points and these points are respective to the origin system (remember: point coordinates stay the same, only the system changes – changed point coordinates mean: We look at them from a different system)!
When the points are then translated, this is done again within the origin system. The translation is completely different as it moves the point within the origin system and not in the rotated one!

It is therefore important to always look at the systems that transformation matrices build: They are multiplied in the natural, obvious order as they are applied.

Example: Create a combined matrix that rotates points by 30 degrees around the point (4,5).

To achieve this, the rotation should happen around the given point, which means we have to move the coordinate system first by applying a transformation matrix T(4,5). Then the rotation should be performed: R(30). Finally we need to undo the translation again, because this was a temporay translation to just change the point of rotation.This is achieved by T(-4,-5).

As a result, we get the combined Matrix C = T(4,5) * R(30) * T(-4,-5)

That is logical, isnt’t it?

I hope this post helps you as much as it helped me writing it and that matrices now lose a bit of their mystery (sorry in case you liked that mistery thingy)

Der Hauptcharakter der Parrot Quest

Das Spiel das ich als Demo für die ParrotEngine gerade erstelle benötigt natürlich einen Hauptdarsteller und wie der Name der Engine unschwer verrät wird es ein Papagei werden. Rechts seht ihr den aktuellen Stand des 3D Models. Ich erstelle alle Modelle in Blender. Der Papagei ist aktuell bereits gerigged und animiert.
Damit es voran geht, werde ich als erstes dieses Model verwenden um ein spielbares Level zu implementieren. Die Feinarbeiten kommen irgendwann später. Falls dies hier ein 3D-Artist liest und dieser fit in Blender ist, nehme ich auch gerne Hilfe an!

Die erste Testmap wird sehr simpel gestrickt sein. Auf dem Screenshot links sieht man den Weg der zurückgelegt werden muss. Links unten ist der Startpunkt (Player Spawn Point) und rechts der Bereich bei dessen Erreichen die Map als erfolgreich erledigt erkannt wird. Der Spieler wird diesen Bereich nicht verlassen können – auf diese Weise kann man sich später im Spiel nicht um Gegner und Hindernisse “herummogeln”. Geheimgänge, Abkürzungen und sonstige Geheimnisse müssen in einer Map gezielt eingebaut werden.

Screenshot des Mapeditors

Um meine Engine nicht alleinig auf Jump’n Run Spiele auszurichten habe ich eine Zwischenschicht eingeführt: Das “JumpNRun Modul”. Dieses enthält neben dem auf diese Art Spiele spezialisierten Map-Editor auch weitere dafür benötigte Hilfsklassen. So bleibt die Engine zwar weniger “mächtig”, dafür aber allgemeingültig und kann später auch für eventuelle weitere Module verwendet werden. Ich denke da an soetwas wie ein “FirstPerson Modul” oder ein “Platform Modul”… doch eins nach dem anderen.

Struktur der Resource Collections

Als Lösung für dieses Problem habe ich die Resource-Collections ins Leben gerufen. Es handelt sich hier um eine Datei im XML Format die eine Liste aller Resourcen enthält die ausgehend vom Ort der resource-collection.xml Datei erreichbar sind. Da die Engine bisher für alle Zugriffe auf Resourcen InputStreamSource-Objekte verwendet, nutzt das Konzept für die Collections diese natürlich ebenfalls. Das bedeutet, dass ein Programm, welches über irgendein InputStreamSource-Objekt an eine resource-collection.xml Datei kam, über genau das gleiche Objekt alle in der XML erwähnten Resource Objekte laden kann!

Die Engine selbst besitzt standardmäßig eine eigene ResourceCollection. Diese enthält neben dem Engine-Logo auch die Standard-Fonts, default-Texturen und Standard-Skyboxen. Damit Programme die die Engine nutzen den Satz an verfügbaren Resourcen ergänzen können gibt es das ResourceCollectionSet. Dieses enthält eine Liste von Resource-Collections.

Das ResourceCollectionSet kann jederzeit um weitere Resource-Collections ergänzt werden. Wird vom Spiel aus eine Resource angefordert, so geschieht das über die ReaderFacade:

 ReaderFacade facade = engine.getReaderFacade();
 MeshPrototype m = facade.readMeshPrototype("meshes/mesh1.xml");
 

Die Methodefacade.readMeshPrototype(…)ruft hier das ResourceCollectionSet auf und dieses sucht dann der Reihe nach in allen registrierten ResourceCollections nach “meshes/mesh1.xml”. Der erste Fundort wird dann genutzt um das Objekt zu laden.

Jede ResourceCollections kann dabei eine andere InputStreamSource besitzen: Netzwerk, ZIP-Archiv, lokales Fileystem, Klassenpfad,… alles ist hier erlaubt.

Um nun auf den eigentlichen Grund dafür zurückzukommen: Es genügt nun die Übergabe eines InputStreamSource Objekts sowie eine dafür gültige Pfadangabe zu einer resource-collection.xml um sicherzustellen, dass eine Menge von Resourcen genau definiert ist. Für die meisten Anwendungsfälle wird es wohl so sein, dass während der Entwicklungszeit das InputStreamSource Objekt eine Instanz vonDirectoryInputStreamSource ist, welches einfach auf ein Filesystem-Verzeichnis verweist. Später, in einem Release wird dies wohl eher ein Verweis auf ein ZIP oder JAR-Archiv sein.

Das ResourceCollectionSet-System ist derzeit nur im Subversion-Repository vorhanden. Es wird aber im nächsten Release der Engine enthalten sein zusammen mit Beispielprogrammen.

Terrain Rendering

Ab sofort ist die Version 0.2 der 3D Parrot Engine verfügbar! Gegenüber der Vorversion wurde die grundlegende Struktur der Engine überarbeitet, das Renderverfahren flexibler gestaltet und eine Menge Performanceoptimierungen sowie Verbesserungen an der Klassenstruktur vorgenommen.

Dieses Release hat als Hauptaufgabe die Basisinfrastruktur der Engine so zu stabilisieren, dass eine feste Grundlage entsteht auf der alle weiteren Erweiterungen implementiert werden können ohne eine erneute Anpassung der Grundstruktur zu erfordern.

Mit dieser Version kommen nun auch einige Beispielprogramme um den Einstieg in die Programmierung mit der Engine zu erleichtern und auch um die Features zu demonstrieren. Das Build-System wurde komplett überarbeitet so dass nun ein einzelnes build.xml alle Aufgaben erledigen kann: Auch das Starten der Beispielprogramme.

Ein Getting-Started Tutorial zeigt, wie einfach mit der Entwicklung mit der Engine begonnen werden kann. Angefangen von der Einrichtung der Entwicklungsumgebung bis hin zum ersten lauffähigen Programm. Die Downloads und weiteren Links befinden sich wie gehabt auf der Hauptseite der Engine.

RenderState Sortierung und Optimierung

Renderstate Verwaltung

Jedes Objekt einer Szene kann ein oder mehrere Materialien verwenden. Ein Material wird über einen RenderState repräsentiert, welcher neben den üblichen OpenGL Material-Settings auch alle Textureinstellungen, die Shader-Programme, En- und Disabled Eigenschaften, den zu verwendenden Polygon Mode, Blend Operationen und viele weitere Eigenschaften enthält. Bei jedem Wechsel des aktiven RenderStates werden nur die OpenGL calls ausgeführt die wirklich notwendig sind. Es ist außerdem nicht notwendig, dass irgendein Objekt weiß welche Einstellungen in OpenGL vorliegen bevor es sich zeichnet – durch das Setzen seines RenderStates kann es sicher sein, dass genau nur die von ihm geforderten Einstellungen aktiv sind.

Realtime Graphanzeige

Ein Timer-Framework hilft dabei Performance-Engpässe zu erkennen und zu beseitigen.

Shader-Support

Die Engine unterstützt Vertex- und Fragmentshader in GLSL. Die Shader sind in die RenderStates eingebettet und werden so als Teil der Materialien angesehen. Die Shader können deklarativ mit Properties im Programm verknüpft werden. Auf diesem Weg können Parameter an die Shader übergeben werden.

Console

Steuerungskonsole

Um zur Laufzeit eine gute Kontrolle über die Engine zu haben und auch um auf ein laufendes Programm direkt Einfluss zu nehmen, gibt es die Console. Sie wird mit der Taste “^” eingeblendet und verfügt unter anderem über eine Historie der Eingabezeilen, Scrollback-Funktion und auch eine Eingabehilfe mit der Tabulator-Taste. Es ist für jedes Objekt sehr einfach möglich Variablen oder Kommandos in der Console zu registrieren und diese damit zur Laufzeit aufrufbar zu machen. Die der Console bereitgestellten Variablen sind so implemetiert, dass kein Performanceverlust dadurch entsteht. Es besteht also kein Grund darin, mit den Console-Variablen sparsam umzugehen.

Frustum Culling

Jedes Objekt im Szenenbaum besitzt eine Kugel die es komplett einschließt. Bevor Objekte gezeichnet werden, wird zunächst diese Kugel auf Sichtbarkeit geprüft und erst wenn die Kugel zumindest teilweise den aktiven Frustum berührt, wird das Objekt selbst auch gezeichnet. Das Terrain wird sogar in viele kleine Teile zerlegt und diese werden dann geprüft – allerdings werden die Terrainteile in Blöcke und nicht in Kugeln eingefasst.

Partikeleditor

Der Partikelsystem-Editor

Mit dem Partikeleditor kann komfortabel ein Partikelsystem aus mehreren Partikelströmen erzeugt werden. Der Editor unterstützt das Live-Verändern von Texturen, Bewegungseinstellungen, Farbverläufen, Größenänderungen, Schwerkraftverlauf, Emitterstärke und einiges mehr. Die so erzeugten Partikelsysteme können in einer XML-Datei exportiert und dann im eigenen Programm durch die Engine geladen in den Szenenbaum eingehangen werden.

Fontcreator

Der Bitmapfont-Creator

Der Fontcreator erzeugt aus TTF-Fonts Schrifttexturen die als Bitmapfonts verwendet werden können.

3D-TTF Text

3D Fonts aus Truetype Fonts

Die Engine kann aus TTF-Dateien 3D-Texte erzeugen. Die Qualität der Texte kann beeinflusst werden und somit ist eine Steuerung der Menge an Geometriedaten möglich die erzeugt werden. Die 3D-Texte sind nach ihrer Erstellung normale 3D-Objekte und auch mit Texturkoordinaten versehen, so dass die normalen Objektoperationen damit möglich sind.

Terrain Rendering mit LOD

Terrain Rendering

Aus einer Heightmap in Verbindung mit einer optionalen Textur kann ein Terrain erzeugt werden. Das Terrain wird unterteilt in ein NxN Raster von Blöcken. Diese werden – je nach Entfernung vom Betrachter – in unterschiedlichen Levels-of-Detail (LOD) dargestellt um die Menge an zu zeichnenden Geometriedaten zu optimieren.

Skybox

Einer Szene kann eine Skybox zugewiesen werden – dadurch ist es einfach möglich einer Szene einen Hintergrund zu geben der sich entsprechend bei der Änderung der Blickrichtung so verhält, als würde er eine weite umliegende Welt darstellen.

Input Handling

Über eine Abstraktionsschicht werden die Benutzereingaben gekapselt und vorverarbeitet. Die Eingaben landen in einer Queue die dann an die in dieser Queue registrierte Listener verteilt werden. Diese Listener erhalten dann die Möglichkeit exklusiv die Eingaben zu verarbeiten oder aber auch nur als Proxy zu fungieren und unverändert passieren zu lassen. Durch dieses Verfahren ist es einfach möglich eine Mouselook-Funktion für ein Programm zu implementieren: Einfach einen TurntableRotator instanzieren und in die Queue einhängen – wenn nun für jedes Frame der Frustum des TurntableRotators geholt und in die Engine gesetzt wird kann man sich schon mit der Maus frei umsehen.

Endlicher Automat

Zur Verwaltung von Spielzuständen und deren Wechsel untereinander ist ein endlicher Automat integriert.

Audio-System

Das integrierte Audio-System unterstützt das Abspielen von mehreren gleichzeitigen Sounds im WAV als auch im OGG-Format.

Blender Export Script

Zur Erstellung von 3D-Objekten ist ein Python Export-Skript für Blender bei der Engine dabei. Dieses Skript muss lediglich in den Skript-Path von Blender kopiert werden und ist anschließend in den Export-Modulen von Blender zu finden. Das Skript exportiert alle selektierten Objekte in einzelne XML-Dateien die jeweils den Namen des Objekts tragen. Wenn Texturen zugeordnet sind, werden diese ebenfalls exportiert. Empties (leere Objekte in Blender) landen als Marker Objekte in den exportierten Objektdateien – damit kann von Applikationen über den Namen des Markers auf deren Position und Ausrichtung innerhalb eines Objekts zugegriffen werden. Die Partikel-Demo nutzt dieses Feature zum Beispiel um die Position des Partikelsystems im Holzstapel zu bestimmen.

Der erste Schnittpunkt den wir finden ist so auf jeden Fall auch der dem Strahl-Startpunkt am nächsten liegende Punkt – was in der Regel der gesuchte Schnittpunkt ist.

Der Weg des Strahls wird verfolgt, indem sowohl dessen Eintritt in, als auch dessen Austritt aus dem Terrain in Heightmap-Koordinaten berechnet werden und zwischen diesen beiden Punkte mit dem Bresenham-Algorithmus eine gerade Linie gezogen wird.

So erhalten wir genau den Bereich, den der Strahl im Terrain zurücklegt und innerhalb dessen ein Schnittpunkt gefunden werden muss falls einer existiert:

Den Strahl mit Bresenham verfolgen

Von der Seite betrachtet sieht man den Verlauf des Strahls und die Schnittpunkte mit dem Terrain:

Seitenansicht der Strahlverfolgung

Die Kreise markieren jeweils den Ein- und Austrittspunkt des Strahls in die achsenparallele Bounding Box (AABoundingBox). Die Quadrate zeigen die so gefundenen Schnittstellen.

Sollte der Strahl innerhalb der Bounding Box beginnen, so wird der Startpunkt des Strahls als Startpunkt für die Strahlverfolgung verwendet.

Feuer mit dem neuen Partikelsystem

Ich habe eine Webstart-Demo online gestellt die den aktuellen Stand des Partikel-Systems in der Parrot Engine zeigt. Das Bild zeigt ein aus Partikeln bestehendes Feuer.

In der Engine gibt es bereits einen umfangreichen Partikel-Editor der das erstellte System per XML exportieren kann. Diese XML-Datei wird direkt von der Engine verarbeitet und das hierdurch definierte System kann anschließend direkt in den Szene-Graphen eingefügt werden. Das Zeichnen und simulieren des Systems steuert dann alles die Engine ganz automatisch.

Beim nächsten Release wird sowohl der Partikel-Editor schon mit dabei sein als auch diese Feuer-Demo und der Alienshooter. Ich hoffe auch, dass ich dazu kommen werde mit dem nächsten Release einiges an Dokumentation mitzuliefern: Eine Referenzdoku sowie ein “Getting-Started” sind wohl erstmal am dringensten.

Intro Screenshot

Ihr könnt den Alien Shooter über Java WebStart starten (aktuell defekt, da JOGL Webstart Libraries nicht funktionieren)

Spielinhalt

Das Ziel des Spiels ist es so viele Punkte wie möglich durch das Abschiessen von Aliens zu sammeln. Die Aliens steigen hinter einer Bergkette auf und überqueren das Spielgebiet bevor sie wieder verschwinden. Der Spieler hat während dieser Passage die Möglichkeit die Ufos abzuschiessen.

Zum Schiessen hat der Spieler eine Kanone mit zwei Rohren die jeweils abwechselnd eine Rakete abfeuern können. Raketen fliegen nicht unendlich schnell, so dass man etwas vorhalten sollte um die Ufos auch zu treffen.

Es gibt Extrapunkte wenn mehr als 70% der Schüsse ihr Ziel erreicht haben und wenn alle Ufos eines Levels erledigt wurden.

Das Spiel endet, wenn in einem Level nicht mindestens die geforderte Abschussquote erreicht wurde.

In der aktuellen Preview-Version gibt es derzeit nur eine Sorte Ufos und 5 Level. Die später folgende, fertige Version wird viele verschiedene Feinde, deutlich mehr Level und ggfls. auch Powerups und Sondermissionen beinhalten.

Bedienung

Die zum Spielen notwendigen Tasten werden stets eingeblendet. Außerdem benötigt ihr die Maus um die Kanone zu steuern und zu schiessen.

Während des Spiels kann mit “ESC” pausiert werden.

Fehler gefunden?

Falls irgendetwas nicht funktionieren sollte, dann sendet mir bitte die Datei “alienshooter.log” aus eurem Homeverzeichnis mit einer Beschreibung was ihr gemacht habt, was nicht funktierte und wie sich das geäußert hat.

Die Log-Datei findet ihr unter einem deutschen Windows XP unter C:/Dokumente und Einstellungen/BENUTZERNAME. Unter Vista findet ihr den Ordner unter C:/Users/BENUTZERNAME. Bei Vista ist es egal ob ihr eine deutsche oder englische Version benutzt.

Ich freue mich natürlich auch über Anregungen, Anfragen, Kritik, Tipps und alles andere an Feedback!

Viele Grüße und viel Spaß – Stefan

Der 3D Font wird in Blender erstellt

Dieser Font kommt nun überall im Spiel zum Einsatz. Der neu erstellte Intro-Screen enthält diesen Font zweimal – jeweils mit einem anderen RenderState. Der Titel des Spiels ist mit einer Textur überzogen deren u/v Koordinaten über einen Fragment-Shader bewegt werden. Der Text unten “Press SPACE to start” entält lediglich einen sehr einfachen Lighting-Shader der einfache Beleuchtungseffekte erzeugt damit der Font räumlicher wirkt.

Screenshot vom Intro Bildschirm

• Die Raketen die der Spieler abfeuern kann haben nun, nach der Optimierung des Partikelsystems auch eine Rauchwolke die sie hinterlassen.
• Titelmusik ist implementiert (von http://audio.ibeat.org/)
• Die Ufos haben nun auch einen Explosions-Sound wenn sie getroffen werden
• Es gibt einen Radar der anzeigt wo gerade Ufos sind – der Spieler muss dann nicht so viel suchen
• Ein Level des Spiels besteht aus mehreren Angriffswellen – definiert über XML-Dateien. So können einfach neue Levels hinzugefügt werden.

Und es geht weiter….