For my master thesis project I developed a terrain editor application to test whether metaballs and 3D noise can be used to procedurally model complex terrain structures such as arches, overhangs and cliffs. Various metaballs were placed in the 3D space to define the overall look of the terrain structure and Perlin noise was applied to it to add irregularities. The core functionality of the terrain editor was implemented on the GPU using OpenCL kernels. The rendering part was handled by OpenGL, Cg was used for the lighting and wire-frame shaders and AntTweakBar was used to implement the user interface. AntTweakBar is a great library and can be easily used in both OpenGL and DirectX (a few lines of code), however it was not the best choice for my editor. The result was a UI difficult to use; you spent more time trying to find the right metaball and move without the use of mouse.
Another huge problem I ran into was the fact that the initial framework I was using had issues with the OpenGL-OpenCL interoperability. The GL-CL interoperability is a way to share GPU memory between the OpenGL and OpenCL context. Specifically, I was using marching cubes to polygonize the 3D volume of the terrain and I wanted my marching cubes kernel to write directly on the position and normals VBOs. The framework I was using (ZephyrEngine) was developed together with Matteo Meli during our summer vacation, however because of technical errors and lack of time we had to drop that project and concentrate on our master thesis. The only problem I had with ZephyrEngine was that the OpenGL-OpenCL interoperability was not working at all. I spent around a week trying to understand why OpenCL kernels could not write to the VBO, but without any success. The contexts were initialized fine, the VBOs were successfully created and the OpenCL kernels were working and writing data to simple CL buffers. After innumerous fruitless attempts I decided to drop the framework and use OpenGL. Because of the technical issues and the lack of time I had to complete the project, my code was (and still is) a bit of a mess.
For those reasons, and my inherent need to learn more stuff, I decided to redesign and redevelop the terrain editor. Specifically:
- Design and implement the User interface in C#: The UI should allow the user to easily add and edit metaballs and other implicit surfaces using the interface. Tools such as translate, rotate and scale will need to be implemented, since I want everything to be done quickly and easily using mostly the mouse. The UI will be the front-end which will get the information from the user and send it to the editor.
- C++/CLI terrain editor render component: I did a bit of research on C++/CLI and I decided to implement a Winform control for the editor’s viewports. The editor will probably have 4 viewports (much like Maya or 3D Max) to easily edit the elements of the terrain. Using C++/CLI will provide me with an easy way to connect the C# UI with the core of the editor.
- Terrain Editor binary using ZephyrEngine: The terrain editor core needs to be redesigned. In order for the core to be redesigned, ZephyrEngine needs to be redesigned. However I still don’t have a clue where the problem in the engine is, so I think the best way is to just start writing it from the beginning and test it along the way, making sure that the problems both me and Matteo had will be solved. Fortunately we’ve got all the code we need, so most of the time will be spent copy-pasting and testing code. Such a nice process…
My first goal is to fix the engine so it will support OpenCL-OpenGL interoperability. At the same time, I will be designing and implementing the user interface in C#. As soon as these are in a working state, I will start coding the editor core and the C++/CLI component.