Some time ago I blogged about the use of a debug server in our 3D game engine. In a retrospective I use it quite extensively. Mostly to check on the logging as it very useful with all those nice colors and hyperlinks to directly see whats happening. Or by simply checking what is loaded.
And here is the result, a simple to use timeline view to quickly see what is taking up too much time.
Further more I have lots of information that I can display, including files and shaders with basic syntax highlighting, documentation with collapsible sections for various items that I can use within my games.
Memory usage and render statistics are also part of the interface. It’s basically one easy to access pile of sorted data. And the HTML output is easy to create, easy to extend, user friendly, and as a bonus, it runs in any browser and you don’t need extra software except a browser – which everyone has.
Note: this web server that spits out HTML is not available publicly, it’s just a means to visualize data that normally is hidden deep inside the system.
In the background we started to create a simple asteroids-clone, similar to NecroSPACE and NecroSPACE 2. The goal is to test our engine for robustness and have another fun game to play which is easy to make!
The winter in the Netherlands was wet and warm with no snow to build a snow man, so we decided to implement our own snow system in our engine.
Basically what we did was use the deferred render normal and depth buffer to determine the normal and the 3D position of a pixel on the screen. Than with a little bit of dot product we created snow that will lay on the top of every object rendered with deferred shading.
Here is a movie of the completed effect.
As seen in the movie, the snow only lies on the up-facing sides of the tree branches.
Weather forecast for the coming game: cloudy with lots of rain!
We wanted to add weather particles to our games. And we wanted A LOT! Our existing particle engine was not capable of simulating millions of particles in real time and we could only add them to a limited area. To solve this problem we added boxed movement and batch rendering for particles. This means that we simulate between 50 to 200 particles in a limited area, say 3x3x3 meters and render this box of particles multiple times in an grid of 3x3x3, having a larger weather cube that follows the camera seamlessly.
We also stretch particles in the direction they move and also by camera movement so you get a star field like effect when you are moving pretty fast trough the rain or snow. Here are two movies to demonstrate the effect.
We can already color the sky and change the lighting, and by adding weather effects we hope to create a more dynamic world with real time changing weather.
A while ago I posted about procedural generating a city. To make it less boring, we added procedural trees – without leaves.
So, where do you start when you want to generate a tree from scratch. Well, first let examine a tree, you have a trunk that goes into the ground. This can be represented by a cylinder that get narrower at the top. Then you have branches, they start at some position at the trunk and also get narrower at the end and can be represented by a cylinder. So we now have we trunk and a branch that can be represented the same way quite easily.
Now we only have to place the cylinders in the world. Placing is pretty easy as the trunk just can be straight and branches can go half way from the trunk to the side with some random offset. Also branches can have branches, so making the code handle this was not an issue and gives a very nice result. But all the branches are straight?! Not when you make them out of multiple cylinders and give them all a small random rotation, then they seem much more organic and gives a pretty nice result.
Just messing around and made a nice screenshot. Currently we have the plan to extend the procedural city generated sky scrapers and a better street network generator. For now we are stuck with some simple quads that are filled in with buildings. Maybe in the future we will also include a terrain engine so we can generate a world with one click of the mouse…
A year ago I was experimenting with damage on our car models. We managed to create a fairly simple way to damage our cars by defining 4 points on the front left, front right, rear left and rear right, that represent the damage on the car. When a car get damage at one of the points, we increase the radius and therefore the damage. Within this radius we calculate a sin/cos on the XYZ to represent dents and pull every vertex a bit toward the inside of car. This is fairly simple and can easily be implemented on the GPU as we did. Also because we have the radius, we can simply add an damage texture.
In the screenshot you can see the damage done to the Blastback of our game FUR. The damage is in the front right corner of the car, closest to the camera.
For the need of animated 3D models we implemented MD5 model support, introduced in idTech 4 (aka Doom 3 engine). This model format is supported in some 3D modelling and animation tools, so it would be a nice choice. There are disadvantages as that the MD5 models and animations are design to be computed on the CPU in stead of the GPU. This will not stop us as this is the first animated model file format that we will support. In the future we may use more formats, but for now it will suffice.
For now we have the Cyberdemon from Doom 3 as test subject and none where harmed during testing…