During the 4th Semester of my studies I wrote a small 3d spaceship deathmatch shooter with the D-Programming language. It was created within 3 Months time and allows multiple players to play deathmatch over local area network. All of the code was written with a garbage collector in mind and made wide usage of the D standard library phobos. After the project was finished I noticed how much time is spend every frame for garbage collection, so I decided to create a version of the game which does not use a GC, to improve performance.
For a university project I implemented the Light Propagation Volumes technique implemented in CryEngine 3 to simulate indirect illumination. I wrote this demo from scratch using OpenGL and the D programming language.
The paper about the alogrithm can be found here:
The model and textures have been taken from the crytek site: http://www.crytek.com/cryengine/cryengine3/downloads
You can download the application for windows including the full sourcecode and documentation here:
To fly around in the scene klick into the 3d window and press M to activate the mouse, then you can fly around using the WASD keys and the mouse. To deactivate the mouse looking press M again.
For everything else you can use the GUI.
Implementation of Light Propagation Volumes von Benjamin Thaut steht unter einer Creative Commons Namensnennung 3.0 Unported Lizenz.
Beruht auf einem Inhalt unter www.vis.uni-stuttgart.de.
As a futher test of the engine I’m currently developing with a friend I wrote this mandelbrot explorer. I’ve implemented software double support inside the mandelbrot shader to avoid the early percission loss. Unfortunately I had to notice that the percission loss is due to the lack of percission during passing the arguments to the shader. Because I had yet no time to also implement pseudo doubles on the cpu, it’s currently disabled.
You can download the application at: http://3d.benjamin-thaut.de/Files/mandelbrot.zip
Currently im creating a game Engine together with a friend for learning porpuses and fun. Because I read the article “Write games not engines” I decided to write a small tetris game with our engine to test the mechanics. During this process I found many flaws and bugs in the engine and fixed them. Also I had lots of ideas how to improve our engine.
The whole game logic is written in lua. Also all draw calls are made by lua. The engine collects the draw calls and executes them later. The engine setup is also done by lua. So the engine is not restricted to forward rendering or deferrend rendering. For this game deferrend rendering was used for learning porpuses. Also I implemented 2 post processing shaders. A edge detection shader and a glow shader. The input is also managed by lua, so it was very easy to write a configurable input system. Even axis of controlers can be used for binary key events because I wrote a small converter in lua.
For small games it is planed to do the logic and draw calls completely in lua. If we some day plan on doing a bigger game like an ego shooter or something like that, more of the logic moves into the C++ code to maintain good speed.
The shaders are generated out of xml files with the option to embed lua code into the xml file, to be able to generate many diferrend shaders out of the same file. In this game this feature was used for the differend qualities of the outline shader.
A huge effort was also taken to use multi threading in the engine. I wrote a task manager that collects all the taks and executes them in the right order, depending on their dependencies to other tasks. To use mutli threading in lua, we wrote data synchronzing commands for lua. Because the multi threading code just went usable recently, this game still runs single threaded because it’s developement startet earlier before.
All displayed strings are indentified by a string name and saved in extern files so this game can be easly puplished in different languages. Currently the game comes with the fowolling languages: german, english and russian.
I know that in this game many things could be solved better, but it was never the aim to go for perfection. Instead this game was only developed to test and improve the engine, to learn lua and for fun.
You can download the game at: http://stuff.benjamin-thaut.de/neswaktek.zip
I’ve read the paper “cascade demo secretes” by Nvidia and wanted to implement a particle system entirely on the gpu myself. So I wrote this small demo. Basicly it works like this:
- Vertexbuffer1 is rendered.
- the geometry shader processes the information (recomputes particle positions, speeds, etc.)
- the result is written into vertexbuffer2 by transform feedback
- vertexbuffer2 is drawn
- the geometry shader creates out of a point a billboard with 4 vertices
- fragment shader renders the billboard with the texture on it
- vertexbuffer1 and vertexbuffer2 are swaped
I wrote this small demo in the past year or so, don’t really know any more when I started.
During this time I developed my OpenGL and C++ Skills and rewrote certain parts of my small
framwork countless Times. Finally I want to start on my first game, so I declare this demo
as finished. I know there would be still much to do and to improve but I simply don’t want
to develop on this demo any more.
Currently it features
- XML shader system (from shader 2.0 to 4.0. System is captable of using geometry shaders but
I didn’t use it in this demo)
- real time shadows (I used a method to improve the quality of the shadows which was developed
by Thomas “Schrompf” Schulze – www.dreamworlds.de)
- Small GUI (used for the value and camera editors)
- value and camera editor (for easily chaning parts of the demo)
- terrain rendering with smooth blending between two detail levels
- Water with “correct” reflections
- some sort of pseudo instancing for the gras. Uses new draw_instanced extension if aviable
- Frustrum culling an lots of other standard stuff
- completely OpenGL 2.0