My master thesis project concentrated on the procedural generation of complex terrain and specifically on the procedural modeling of structures such as arches, overhangs and cliffs, observed in nature. One of the most popular ways of creating such terrain structures is to create a density function which samples pseudo-random 3D noise in various frequencies and adds them together in various amplitudes. The density function basically fills a 3D grid which represents the terrain patch. That volume gets polygonised using the marching cubes algorithm to generate the terrain’s surface which can be rendered with any rendering engine (no need for volumetric rendering this way).
The goal of this project was to find a way of procedurally modeling the desired structures (arches, overhangs and cliffs) by explicitly defining them in the 3D space. Using only 3D noise can generate such structures, but it’s quite difficult to specify where they will show up. The approach taken was to use metaballs to define the general look of the structure and several noise samples to add irregularity (more “natural” look) to it. The project was inspired by Ryan Geiss’s article in GPU Gems 3, and his “cascades demo”.
In order to model the desired structures and test whether or not it was possible to procedurally model them using metaballs and noise, I developed the “Terrain editor” application. The terrain editor allows a single terrain patch (limited size) to be generated almost completely on the GPU. The process followed to generate a patch is the following:
- Get the user’s preferences first (positions of metaballs, noise samples, etc).
- Execute the terrain density function kernel which fills the volume that contains the terrain data. The noise textures the function samples from are generated on demand, that because generating the noise real time results in slower execution.
- The volume gets polygonised after executing the marching cubes kernels and the vertex and normal buffers get filled up with the terrain geometry.
- The terrain geometry gets rendered on the screen using OpenGL and a simple CgFx lighting shader.
The “Terrain editor” application uses OpenCL to parallelise the generation of 3D Perlin noise, the terrain density function and the marching cubes algorithm. Thus most of the “heavy” work is done on the GPU. The rendering is handled by OpenGL and NVidia CG for the shaders. The OpenCL/OpenGL interoperability is used to share the vertex and normal buffers between OpenGL and OpenCL. Unfortunately the application was developed using OpenCL version 1.2, which is currently not supported by NVidia, therefore the editor as it is won’t execute NVidia GPUs. I worked on my master thesis from September 2012 to January 2013.
C++, OpenCL, OpenGL, Cg, Procedural generation of complex terrain.
The ZephyrEngine was developed by Matteo Meli and me as a framework for our master thesis projects. The main idea when designing the engine was to design it in such a way that it could easily expanded to support OpenGL and DirectX as well as OpenCL and Cuda. NVidia’s Cg library was used to support shaders and effects. Because of lack of time and some technical problems, specifically problems with OpenGL-CL interoperability, the project was dropped. We worked on this project during the summer of 2012.
Work I’ve done: Shader manager (Cg), hardware buffers (vertex, index) interfaces and some implementations, GPGPU manager (OpenCL).
C++, OpenGL, OpenCL, Cg