eVoid Development Weblog Burn The Land And Boil The Sea But You Can't Take The Sky From Me

23Jul/100

Alpha 2 & Resource Organization

Today I finished the last tasks I had queued for alpha 2. Furthermore I've put a snapshot of the recent version online accomplished by some documentation. By doing so I decided to share some thoughts on the organization of resources by contexts and I'd like to draw your attention to it: What's your opinion on my solution, how do you handle it?

I've also written a roadmap for the project:

  • Alpha 1 (5. February 2010)
    • First usable version with a basic implementation of all the most important features, those are:
      • Post Processing Pipeline: Satisfying the demand on being easy to use, effects like blooming can be activated by up to three lines of code.
      • Object oriented encapsulation of most important OpenGL elements like textures, frame buffer objects and many more, providing the paradigm of orthogonality while satisfying the demand on being flexible & robust.
  • Alpha 2 (23. July 2010)
    • Countless bug-fixes & increased robustness
    • Widely improved GL encapsulation
    • Straightforward user-oriented design
    • API completely re-organized by layers

      ← Here we are
  • Alpha 3
    • Implementation of per-object motion- & usual blurring
    • Material property for specular highlighting
    • GL/gl.h dependency removal from vertexbuffer.hpp
    • Lazy state changes to avoid redundancy
    • Major API changes
      • Renderer class merged into RenderTarget
      • Materials organized by resource contexts
      • Potentially some kind of a shader abstraction:
        - Stack-like organization of shader states
        - Automatized shader generation
  • Share/Bookmark
5Jul/102

Update + Thoughts of Quad- & Octtrees

Even though I didn't update that blog during the past few months, the work proceeded quite well. A countless amount of bugs has been fixed, the abstraction from OpenGL improved a lot and the API itself completely revised. I've outlined a road map of what still has to be done 'til Alpha 2 and it's not that much:

  1. Implement DefaultMesh::CreateSphere
  2. Implement DefaultMesh::CreateCylinder
  3. Implement DefaultMesh::CreateCone
  4. Solve Bloom-zBuffer-Problem
  5. Clean up some header files

So #1 was an ease and now I'm still almost done with #4 which is the last greater task. The problem here was that rendering with bloom worked like a charm but when rendering in combination with objects that should have been not affected by the bloom effect, the depth-buffer information messed up. The bad thing about it is that I finally reached the limits of the possibilities of my GeForce 6600 and am not able to proceed right now, for I also don't have the money to buy me a new card. So it's fairly probable that I won't continue work on this task until September, when I expect to get a new notebook bought by the institute I will start working at, namely the Institute for Medical Engineering as an appliance.

So I spent a few thoughts on the later organization of the world data in octtrees recently when I was bored. The following short article will describe a way of organizing the nodes of a quadtree (for the sake of clarity) in a certain way which allows a very easy and straightforward traversal of the tree. It is trivial to expend this technique to work with octtrees.

  • Share/Bookmark
22Jan/100

Deferred Lighting

Some days ago I finished implementing a deferred lighting system. That's a shader driven lighting system that scales very well with lots of light sources because redundant vertex transformations are being avoided and was used in recent top-seller games like S.T.A.L.K.E.R. or Crysis. This is achieved by rendering the whole scene into a so called G-Buffer, where the 'G' stands for 'geometry', in a first pre-pass. Currently I'm using MRT with three 16 bit floating point RGBA textures which means that I have 12 channels for every fragment in my G-Buffer. I would prefer using two 32 bit floating point textures instead, so I would have 16 channels by packing two 16 bit values into one 32 bit field, but my ancient GeForce 6600 doesn't support Shader Model 3.0 which is required for bit-wise operators.

  • Share/Bookmark
22Dez/090

Current Project (yet unnamed) Update

The basic material functionalities, like browsing available materials and assigning them to the material slots of instantiated tiles, are finally implemented now. Actually I wanted to to implement bump mapping next, and that's still the thing I'm going to do, but I noticed that I will have to completely rewrite the way tiles are loaded first and introduce a different tile definition format.

  • Share/Bookmark
30Jun/090

Resources Detail Stack

Die im Folgenden vorgestellte Datenstruktur kann verwendet werden, um verschiedene Detailstufen einer Geometrie zu verwalten. Sie wird besonders der Annahme gerecht, dass die Frage, wie viele Detailstufen eine Geometrie hat, allein ihre eigene Sache ist, was die Portabilität und Erweiterbarkeit deutlich fördert.

  • Share/Bookmark
30Jun/090

Trigger

Trigger sind ein in Spielen weit verbreitetes Konzept. Hier möchte ich nur einige meiner spontanen Gedanken zu dem Thema vorstellen, ich habe micht zu dem Thema selbst kaum informiert und erhebe für den folgenden Artikel darum auch nicht den Anspruch, den Königsweg zu beschreiben. Ein Trigger, zu Deutsch 'Schalter', ist eine abstrakte Einheit, die durch das Eintreffen einer bestimmten Bedingung ausgelöst wird, etwa wenn eine Spielfigur ein markiertes Feld betritt. Im Folgenden möchte ich einige Gedanken zu solchen Triggern offenlegen, die durch den Ablauf einer Zeitspanne ausgelöst werden, ich bezeichne sie im folgenden einfach als Timed Trigger. Solche Trigger lassen sich sehr vielseitig einsetzen, neben dem Offensichtlichsten, etwa dem Auslösen eines Ereignisses im Spiel nach Ablauf einer bestimmten Zeit, lässt sich das Konzept sehr einfach erweitern, um Conditional Trigger zu implementieren, also solche Trigger, die durch das Erfüllen einer beliebigen Bedingung ausgelöst werden.

  • Share/Bookmark
11Jul/080

Interessante Artikel bei Gamasutra

Zufällig bin ich bei Gamasutra auf vier sehr interessante Artikel zu diesem Thema gestoßen: Der Autor äußert einige teilweise sehr interessante Ideen zur Modellierung und Darstellung eines ganzen Universums von der größten Galaxie bis hin zum kleinsten Hügel eines Planeten.

Part 1: Generating Planetery Bodies
Part 2: Rendering Planetery Bodies
Part 3: Matters Of Scale
Part 4: Dynamic Ground Textures And Objects

Besonders Teil 1 und 3 sind sehr aufschlussreich: Die Idee "dynamischer" Algorithmen zur Generierung von Geländedaten "on the fly" mit festem Random-Seek, so dass die Ergebnisse immer dieselben sind, zum Einsparen sonst notwendiger Gigabyte an Daten; sowie die Aufteilung der Welt in hierarchische Bezugssysteme (Frame Of Reference), zwischen denen flüssig hin- und hergewechselt werden kann.

Nachtrag 13.7.2008: Im Konzept der hierarchisch angeordneten Bezugssysteme, wobei man sich wohl auf eine Unterscheidung zwischen Kilometer-Bezugssystem und Lichtjahr-Bezugssystem beschränken kann, bietet sich die Implementierung eines Scene-Graphen förmlich an. Die Handhabung der verschiedenen Bezugssystem, insbesondere das Umspringen von einem in ein anderes, werden dadurch zum Kinderspiel.

  • Share/Bookmark
2Sep/070

Terrain-Engine: Chunked LOD

In der Frage nach der Vereinfachung des Geländes habe ich mich für eine Methode entschieden, die ich hier schildere. Der QuadTree wird von unten nach oben, also von den Blättern zur Wurzel, durchlaufen. Dadurch wird sichergestellt, dass jeder Knoten, der bearbeitet wird, bereits über vier Childs mit Geoemetrie-Daten verügt. Dabei wird auf jeden Knoten, bei dem es sich nicht um ein Blatt handelt, der eigentliche Chunked LOD angewendet. Dabei wird jeder Knoten so betrachtet, wie es das nachfolgende Bild zeigt - Aus vier Childs bestehend, derer Geometrie-Daten unregelmäßig aufgelöst sein können.

Chunked LOD 1

Auf den Knoten bauen wir mittels Rekursion einen temporären QuadTree auf, dessen Wurzel den gesamten Knoten abdeckt. Die Childs erster Generation sind die Childs des gesamten Knoten. Die Blätter des temporären QuadTrees erfassen jeweils vier Vertices der Childs. Letztendlich unterteilen wir also jeden der vier Childs des gesamten Knotens weiter. Dabei wird bei jeder weiteren Unterteilung überprüft, ob der Abstand der Eckpunkte des Knotens noch größer 1 ist; ist er das nicht, wird die Rekursion beendet und der Knoten als Blatt markiert. Ist der Abstand größer 1, wird überprüft, ob in der Mitte des Knotens ein Vertex existiert, der dann als Eckpunkt für vier weitere rekursive Aufrufe verwendet wird. Existiert der Vertex nicht, haben wir ein weiteres Blatt für unseren QuadTree gefunden. Immer, wenn wir ein Blatt finden, brauchen wir nur Vertex- und Index-Daten für dieses zu generieren.

  • Share/Bookmark
20Aug/070

Terrain-Engine

Mit Hilfe der Terrain-Engine sollen sich ganze Planeten visualisieren lassen - Was natürlich bedeutet, dass man mit sehr großen Terrain-Daten hantiert. Ich habe mich in einige Algorithmen zur Verarbeitung von großen Terrains eingelesen und mich für das Chunked LOD entschieden. Zur Generierung der Terrain-Daten habe ich den guten alten Sub-Division Algorithmus vorgesehen, mit dem ich bereits gute Erfahrungen gemacht habe.

  • Share/Bookmark
10Sep/060

Altitude Map

In den vergangenen Wochen habe ich mich etwas tiefgehender mit der Funktionsweise von Geländegeneratoren beschäftigt und selbst einen in C++ implementiert. Dabei habe ich primär vom Subdivision-Algorithmus Gebrauch gemacht - Im Prinzip teilt dieser die zu erzeugende Höhenkarte in immer kleinere Rechtecke auf, indem der Mittelpunkt des ursprünglich gewählten Vierecks als Eckpunkt von vier neuen Vierecken interpretiert wird. Dieser Mittelpunkt wird um einen zufälligen Wert, der aber nach bestimmten Gesetzen ermittelt wird, angehoben. Auf diese Weise, und um einige zusätzliche Mechanismen, wie z.B. einem Erosionsalgorithmus, erweitert, lassen sich interessante Gelände generieren.

  • Share/Bookmark