I plan to implement a volume renderer for large meshes like terrains. Ideally this would become a full fledged volume terrain component for Ogre over time which I will support and be responsible for the ongoing development. After the summer I will maintain this subproject, complete existing features and add new. This GSoC is aimed at creating a prototype. The license will be the same as OGRE itself, MIT.
The heart of something like this is a LOD algorithm. One of the few current available resources here is the Transvoxel algorithm [1]. But I think it has a major drawback: So many triangles due to the modified Marching Cubes. So my idea is to take Dual Marching Cubes [2], which is much sparser in triangles where they aren't needed. It also preserves sharp edges.
This image compares the source (upper left), the marching cubes version (lower left), the dual contouring version (lower right) and the dual marching cubes version (upper right).

One nice thing about it is, that it is a somehow simple concept made of several quite independend steps (generating the octree, isolating features, creating the dual grid, applying marching cubes to the dual grid). So there are several options to modify it to the needs or to save some time (like not isolating features via QEFs but to take the center of the octree cells for it).
The LOD part of it would be similar to Chunked LOD Terrain [3] where the single chunks are closed so the cracks are already filled. With closed I mean this: To generate a chunk, there's always a part of the volume data, a cube, to be used. At the planes of this cube, the isosurface would have open parts as it is "cut" out of the rest. See the dark gray part of the following image (lousy programmer art). When this open parts are triangulated and closed, no gaps can occure anymore when two chunks of different resolutions are drawn together.

This triangulation can be achieved in two ways and it must be evaluated, which one is better.
a) Use some kind of CSG to cut the volume data cube out of the complete volume data
b) "Just" triangulate the open parts.
b) seems to be much more complicated and my feelings are, that a) is the way to go.
Another thing to consider and evaluate while the project is running, is the generation time of the chunks. If it is too long, the generation can be a preprocess with the binary data being saved to a file. The loading time for the user would be then just the reading of the file from the disc.
Polyvox could be a valuable library. This evaluation comes after implementing the dualgrid (which is the biggest part). It might be used for:
- loading the volume data
- applying the marching cubes to the dualgrid

The central part for generating the meshes is the MeshGenerator. It uses a VolumeSource as representation of the density function with getValue(x, y, z). There the three steps of the DMC mesh generation happen. The Octree is generated via the VolumeOctree classes, FeatureIsolator and Contourer have it's own creation classes (maybe they aren't needed and can also be directly in the MeshGenerator, implementation will show). The outcome is an instance of TerrainChunk.
The OcreeGenerator will create the volume octree consisting of VolumeOctreeNodes. The octree starts with a root node containing the complete volume and splits into octants if the VolumeOctreeSplitPolicy says so. This goes on recursivly until the policy says false. The first implementation uses the VolumeOctreeNodeGridSplitPolicy which is a regular grid over the VolumeSource and split if there are enough gridpoints near the isosurface (== density < epsilon). The dual marching cubes paper proposes splitting with quadric error functions (QEF) which would be VolumeOctreeNodeQEFSplitPolicy using the class QEF. But the grid approach will be good enough for the first octree generation.
VolumeSource is an abstract class which is the source of the volume data. The first implementation is a small CSG. It consists of the following classes:
- CSGSphereVolumeSource: Generator for a sphere volume, center and radius given
- CSGPlaneVolumeSource: Generator for a plane volume, hessian normal form given
- CSGCubeVolumeSource: Generator for a cube, center and dimension given
- CSGOperationVolumeSource: Abstract class for the CSG operations, holds two pointers to a VolumeSource as operants
- CSGIntersectionVolumeSource: Intersection of two VolumeSources
- CSGUnionVolumeSource: Union of two VolumeSources
- CSGDifferenceVolumeSource: Difference of two VolumeSources
- CSGNegateVolumeSource: Negation of a VolumeSource
TextureVolumeSource (also already implemented) loads volume data from volume textures. This is usefull for tools like Acropora [5] which can export the volume data as 3D dds. It uses either trilinear interpolation or nearest neighbour to access the discret values.
TerrainChunk is the octree with the separate LOD meshes and used for rendering. activateLODLevels() traverses the octree and en- / disables the LOD chunks depending on the position of the given camera. It is derived from SimpleRenderable which offers a nice base for the actual rendered things in OGRE.
Of course, there is the risk, that not everything works out as I imagine as this is a more or less new approach for volume LOD, but I'm very confident here.

Schedule
- Mai 21. - Mai 27.: GSoC start. Evaluation of what's done (Masterthesis starts earlier) and planned. Setting up the exact implementation plans for the GSoC part which also might shift this roadmap.
- Mai 28. - June 03.: Working on Octree generation
- June 04. - June 10.: Octree generation done
- June 11. - June 17.: Working on Dualgrid generation
- June 18. - June 24.: Working on Dualgrid generation
- June 25. - July 01.: Dualgrid generation done
- July 02. - July 08.: Working on Marching Cubes
- July 09. - July 15.: Marching Cubes done
- July 16. - July 22.: Working on LOD part
- July 23. - July 29.: LOD part done
- July 30. - August 05.: Working on simple material system with triplanar mapping*
- August 06. - August 12.: Simple material system with triplanar mapping done*
- August 13. - August 19.: Refactoring and generalizing, buffer
- August 20. - August 26.: Refactoring and generalizing, buffer
- August 27. - August 31.: Final GSoC touches and handing in
This roadmap is outdated and only kept to have the initial proposal intact. The most current roadmap is in the Wiki article!
Why You're The Person For This Project
I've finished my bachelors degree in media computer science in 2009, worked then for a year as a developer in a small game studio and then started my master in 2010. This project is my masterthesis and so I have a lot of motivation to make it a success.

I'm a experienced C++ programmer, using this language in some projects now since ~7 years. This includes the implementation of a scenemanager in Ogre providing an implementation of Chunked LOD Terrain and with occlusion culling which resulted in a paper being published at the "
6. GI-Workshop "Virtuelle und Erweiterte Realität"" (6th workshop of the society of computer science "Virtual and Augmented Reality") [6].
Why OGRE?
OGRE is a great 3D graphics library. The main use case for this project is of course volume terrain with cliffs, hangs and caves. A component like this would give OGRE something which is not (yet) often seen.
For me, OGRE is also the ideal platform because I have some experience with it and don't need to start this project from scratch with low level OpenGL.
Infrastructure
- Public viewable repository: https://bitbucket.org/philiplb/ogrevolumeterrain/
- Wiki-Entry with weekly progress: http://www.ogre3d.org/tikiwiki/SoC2012+ ... at+terrain
[2] http://faculty.cs.tamu.edu/schaefer/research/dmc.pdf
[3] http://tulrich.com/geekstuff/chunklod.html
[4] http://http.developer.nvidia.com/GPUGem ... _ch01.html
[5] http://www.voxelogic.com/index.php?opti ... &Itemid=21
[6] http://www.dlr.de/sc/en/desktopdefault. ... ead-17273/