GPU Terrains

Introduction

Thanks to a night at Encelo’s flat that meant some discussions (several beers… ) and a bit of testing I’ve improved a lot the performance of almost all the shaders!

I’ve continued to work on optimization for another day, and now I’m really satisfied of the results I’ve obtained, in most of cases the improvements are amazing, as you will see in the benchmarks I’m going to publish in the next posts.

In this discussion I’m going to talk about a couple of optimizations for shaders coding.

Optimizing the two phases shaders

As I’ve described in my previous posts, the first three thermal erosion shaders are based on two different phases.

In my first implementation I put the code of both phases in a single shader and the program decided what phase to execute according to a uniform variable “phase” and an if branch.

I’ve discovered this is a bad way of coding, the best way is split the two phases in two different shaders, attach them to two different shader programs and call the appropriate program inside the GL application keeping the logic branch there.

Optimizing the shaders execution

Thanks to the previous optimization I’ve started to attach every single shader to a different shader program, and (re)call the program when needed, i.e. the associated key is pressed.

Before of that I used a single shader program and I attached to it a different shader every time it was needed, this way required a linking at every execution and I suppose it requires several other operations hidden inside the GL/graphic pipeline, taking so much more time to execute the shader.

Some minor optimizations

Some minor suggestions to keep in mind are:

• use GLSL functions also for simple code as the cross product
• avoid type casting and use floats all the times that are required computations (usually GLSL functions requires float and so they built-in variables are)
• use the latest video drivers, updating my NVIDIA video drivers from 100 to 169 version improved thermal erosion shaders by about 10%.

Introduction

In the last days of work I’ve merged the 3D engine with the Perlin Noise generator, now I can see a new 3D terrain just pressing a key, so cool!

The current version of the program is quite “rough”, mostly because the program is more a proof of concept than a real application, so I’m not wasting many time thinking about how to manage everything, all you’re going to read above it’s just a description of how the things are at the moment and not a guide about how things should be in a “perfect” engine.

The generation Process

In order to get a textured terrain I’ve created a kind of “generation pipeline”, the main steps are the following:

• the heightmap is generated by the Perlin Noise shader
• the texture is normalized by the normalization shader
• the height values are dumped from the texture and stored in the array passed to the 3D rendering function
• the color texture is generated by the procedural texture generation shader

Everything is done using a single Ping-Pong Texture (a couple of texture attached to a FBO).

Computation and Visualization

Using the same program for GPGPU computing and for 3D visualization requires a bit of code to manage the change from one status to the other one. Above there are the two methods I’ve added to the Screen class to accomplish this change.

The first one is called before the GPGPU phase:

void graphic::Screen::StartComputationMode(GLint w, GLint h)
{
    glPushAttrib(GL_ENABLE_BIT | GL_POLYGON_BIT);

    glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);

    glDisable(GL_DEPTH_TEST);
    glDisable(GL_CULL_FACE);

    glMatrixMode(GL_PROJECTION);
    glPushMatrix();
    glLoadIdentity();
    glOrtho(0.0, w, h, 0.0, -1.0, 1.0);

    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();

    glViewport(0, 0, w, h);
}

the main purpose of this method is setting the orthogonal projection and disabling everything that can interfere with the computation, furthermore it updates the viewport to the texture dimension.

It’s important to notice how all the changes are made after matrix pushes, that means it’s possible to restore the GL context just with a couple of matrix pops, like showed in the following method:

void graphic::Screen::EndComputationMode()
{
    glMatrixMode(GL_PROJECTION);
    glPopMatrix();

    glMatrixMode(GL_MODELVIEW);
    glPopMatrix();

    glViewport(0, 0, _width, _height);

    glPopAttrib();
}

After this method is called, the visualization can restart with no problems.

Introduction

The new version of the engine comes with a couple of interesting new features… texturing above all!

I see the colors!

As I’ve already introduced, the main feature in this new version of the engine is the use of textures for coloring the terrain

The previous images shows a terrain with no color texture (top left panel) and the same terrain rendered in the 3 different polygonal modes with texture.

Now, if no texture file is passed to the CLI, the program uses the heightmap as texture.

A change related to the use of color textures is the new color of the fog:

now it’s gray, giving a more realistic look.

The last new feature is a minimap drawn on the top left corner of the window, it’s useful to show the heightmap image and compare it with the 3D rendering:

I’ve also fixed a bug in the terrain rendering, now the terrain is drawn according to the right orientation (as showed by the image above).

Source code

The source code of this version is available here: 3D_terrain-0.5.1.tar.gz

UPDATED on 2008/06/19 replaced the file with a new version that fixes some bugs and adds frame rate control.

In order to compile the code you need: SDL, SDL_image and scons.

To know options and commands run:

3D_terrain -h

Introduction

This day I’ve introduced another new feature to the engine: fog!

Misty days

OpenGL offers 3 different models for fog, the new version of my terrain engine allows to test them all just pressing a key:

The top left panel shows the terrain with no fog, the top right panel shows GL_LINEAR fog, the bottom left shows GL_EXP fog and the bottom right panel shows GL_EXP2 fog.

Of course the last one is the more realistic, but fog generated with GL_LINEAR is quite similar and it’s faster to compute.

Another news that it’s possible to notice from the previous image is that now the background color of the scene is blue, similar to the default background of Blender, this is not just a “tribute” to the 3D program, but it’s a way to have a better contrast between the terrain and the background.

Instead the color of the fog is totally a tribute to the fog used in “Warhammer 40k, Dawn of War“, a game I’m playing with in this period

Source code

The source code of this version is available here: 3D_terrain-0.4.0.tar.gz

In order to compile the code you need: SDL, SDL_image and scons.

To know options and commands run:

3D_terrain -h

Introduction

Another improvement of the terrain engine, now it can render something more than simple points!

New features

Now the program is more an engine (even if really simple and not optimized) than a simple demo as in the previous version, the main news is the replacement of points with polygons (triangles, to be precise).

In this version is possible to render the terrain using points, not filled triangles (lines) and filled triangles, as showed in the following screenshots:

Using triangles instead of points allows also to notice better how the sampling level affect the rendering:

Source code

The source code of this version is available here: 3D_terrain-0.3.0.tar.gz

In order to compile the code you need: SDL, SDL_image and scons.

To know options and commands run:

3D_terrain -h