Project Information

Proposal and discussion thread: http://www.ogre3d.org/forums/viewtopic.php?f=13&t=69449
Mercurial repository: https://bitbucket.org/philiplb/ogrevolumeterrain/

Roadmap

Some objects on the following roadmap are pessimistically estimated like the implementation of Marching Cubes, some of them can be extended like whatnot like the material stuff. So the actual implementation might move. This roadmap is updated whenever something changes of course.

• Mai 21. - Mai 27.: GSoC start. Working on non ambigous Marching Cubes implementation.
• Mai 28. - June 03.: Marching Cubes done
• June 04. - June 10.: Working on LOD
• June 11. - June 17.: Working on LOD done
• June 18. - June 24.: Revisiting the octree generation, research on Adaptive Distance Fields as split policy and / or QEFs again or something completly different. Also making things somewhat more usable.
• June 25. - July 01.: Refactoring storage and handling of the geometry to reduce batch count, more optimizations.
• July 02. - July 08.: Extending the triplanar texturing to a fullblown shader with lights, fog, etc..
• July 09. - July 15.: Triplanar Texturing reference shader done. Loading basic (non-CSG) terrain from a config file. Starting to have a deep look at the WorkQueue to parallelize loading of chunks.
• July 16. - July 22.: Have a deep look at the WorkQueue to parallelize loading of chunks.
• July 23. - July 29.: Having a RTTSSystem triplanar component with and without normalmapping.
• July 30. - August 05.: Having a RTTSSystem triplanar component with and without normalmapping done.
• August 06. - August 12.: Move the actual volume rendering code to a plugin
• August 13. - August 19.: Testing, bells & whistles, refactoring, optimizing, documentating, buffer
• August 20. - August 26.: Testing, bells & whistles, refactoring, optimizing, documentating, buffer
• August 27. - August 31.: Final GSoC touches and handing in

Weekly Progress

2012-04-29

• Done so far: Some CSG VolumeSource, untested 3d texture VolumeSource, generating an Octree out of the volume with debug visualization
• Forked Ogres Repo
• Ported playground project from own application to an Ogre sample project
• Adjusted all code to Ogres style guide
• Wiki page created

2012-05-06

More warmup and making a comfortable environment.

• SDKTray TextBox, Main Sample class is registered as LogListener and fills it.
• Checkbox for showing and hiding the octree.
• Hotkey "h" hides/shows all UI elements, nice for screenshots.
• Read the first half of "Effective C++" 3rd edition to brush up my C++ knowledge. Highly recommended book!

2012-05-13

As the Summer of Code hasn't officially started yet and also my Thesis waits for some formal stuff, I tackled
mostly stuff which is nice but not super directly relevant to the LOD isosurfacing: Triplanar Texturing! And
some other small stuff. 😊

• Triplanar Texturing with a small test-mesh, implemented as CG shader.
• Finished "Effective C++". Now that went into detail...
• Began a DualCell class which currently just holds 8 corners and can add them to a manual object for debug visualization. Next step is to traverse the octree and generate the dual cell grid.

2012-05-20

Slowly actually getting started.

• Completed the CSG cube
• Implemented the construction of the dual grid with a (switchable) debug visualization
• Put a new roadmap in the Wiki

2012-05-28

Working...

• Added some first documentation.
• Implemented a MeshBuilder to build up a mesh from triangles using vertices and indices without duplicating vertices.
• Started with Marching Cubes.

2012-05-29

Because the previous entry had no screenshot. First working Marching Cubes! 😀

2012-06-03

First closed gaps.

• Added a checkbox to hide and show the actual mesh.
• Using the cells of the DualGrid for Marching Cubes now.
• Updated the roadmap as the Marching Cubes stuff was earlier done than expected.
• Implemented Marching Squares to triangulate the open parts of the (future) chunks.

2012-06-10

First rough LOD.

• Finished the triangulation via Marching Squares for the open parts of the chunks.
• Updated the roadmap, added the plugin point.
• Changed the Octree grid split method to use some kind of geometric error.
• Moved Mesh Generation to the class Chunk.
• Finished a first LOD version with chunks and approximated pixel error.

2012-06-17

Making things more usefull.

• Made the TextureSource working with some real data coming from the editor Acropora.
• Added the possibility (switched on per default) to use trilinear interpolation of the normal in TextureSource.
• Some big loading time optimizations.
• Added a CSGUnarySource as abstract parent class, CSGNegateSource is now a child class of it.
• Added a CSGScaleSource (CSGUnarySource is the parent class) which scales the given Source. Good for scaling a TextureSource to the desired size.

2012-06-24

Optimizations and getting a bit towards something for the real world.

• Updated the roadmap as the LOD stuff was done one week early and I'm happy for now with the Octree.
• Changed the density function Source::getValueAndNormal to Source::getValueAndGradient.
• Using a new OctreeNodeZhangSplitPolicy, some kind of this method extended: http://www.andrew.cmu.edu/user/jessicaz/publication/meshing/
• Don't generate those border/skirt triangles on the border of the world. Not needed here and saves a lot of triangles.
• Put the volume textures in a zip to decrease IO loading time.
• Don't generate chunks which don't contain triangles and don't patch cracks. This decreases the batchcount.
• Implemented a CacheSource. Might be usefull for very expensive (nested CSG) sources.
• Using far better normals for the crack patching marching squares.
• Added a debug/documentation visualization of the MC configurations, the key m switches through all 256.
• Switched off the handling of ambigous cases in marching squares as it caused a crack (this took some hours of debugging...).

2012-07-01

Scratching itches.

• Changed the chunks from being closed with marching squares to just some skirts, also with marching squares. This saves 42% of the triangles for the testscenario!
• A bit more tweaking on the skirt normals. Some blending can be configured now from the outside.
• Introduced ChunkParameters as parameter of Chunk::load to clean up this giant amount of parameters a bit.
• The drawing octree leaves and their parents have the same size now. So the node before the leave doesn't split up into eight children but into one. The eight would be all drawn anyway so they can be one mesh. Saves again a lot of triangles (no more skirts here) and reduces the batchcount to something usable.
• Found an error in the OctreeNodeZhangSplitPolicy causing those big differences between chunks.
• Found an error in the Triplanar Texturing shader causing some bad lighting.
• Added the point "Loading basic (non-CSG) terrain from a config file." to the roadmap.
• Added the point "Have a deep look at the WorkQueue to parallelize loading of chunks." to the roadmap./list

As the geometry and lighting is now nice and smooth, I initially wanted to post a video today. But unfortunatly, my router died yesterday due to a thunderstorm here and I'm on a crappy UMTS connection for the next days. So only a screenshot again.

2012-07-08

Bringing the shader to live.

• Supporting up to 3 lights in the shader.
• Supporting light attenuation in the shader.
• Supporting spotlights in the shader.
• Supporting fog in the shader.
• Supporting normal mapping in the shader.
• Added some ideas for later to the wiki.
• Added a possibility to get all chunks of a specific LOD level.
• Added a callback to get the actual meshdata of a specific LOD level while loading.

Ideas

Here I collect ideas which could be implemented in the future, likely after the GSoC. But nothing is guaranteed here, just collecting. 😊

Paging

Needed for really large worlds.

CSGXML

A xml format to define "scenes" outside of the code. Something like this:

<csg>
  <union>
    <sphere radius="5" x="5" y="6" z="7" />
    <texture src="terrain.dds" width="200" height="200" depth="200" />
  </union>
</csg>

Rays

Needed for picking and physics. But what to take here?

• Keep the Source and use this for intersection searching. Pro: More easy to find them. Con: Can be memory heavy (if the source contains a big 3D texture) and as the generated triangles are naturally only an approximation of the volume, it won't be triangle-perfect.
• Keep the DualCells of the highest LOD level. First pick the chunk candidates by using the AABB of the chunks and then walk through the dualcells. Test them for hits. And if so, generate internal triangles on the fly and test them. Pro: Less memory heavy, but could be still heavy. I have to find out, how to intersect rays with (often degenerated) cube-like thingies. Pro: Could be fast due to the nature of this broad-, middle- and nearphase.
• Test first the AABB of the chunks with the highest LOD level and then the triangles. Pro: No additional memory required (Is it so? Are vertices and indices still available after they are sent to the GPU memory?). Not that slow. Con: Skirt triangles might be also taken into consideration and this is not desired.

Mesh Voxelisation

Union a voxelized mesh with your terrain and you get Mount Rushmore. 😊
Good Source: http://procworld.blogspot.de/2011/04/opencl-voxelization.html

Heightmap Voxelisation

So existing heightmaps can be used. This guy did it: http://www.guildhall.smu.edu/fileadmin/Masters_Thesis_PDFS/Software_Development/Talaber_ThesisProject_RevFinal.pdf
And also those guys do it: https://www.gitorious.org/thermite3d/thermite3d/blobs/master/Heightmap2Volume/source/main.cpp But both don't save the distance to the surface but just whether the voxel is in or out...

Maybe some indirect way with first generating a big mesh? Memory and CPU heavy...

Idea: Some image processing kernel like stuff.
You start for example with this 1D heightmap (O is out of the volume, X within):

Initialize the volume with zero:

Iterate with a 3x3 kernel, central hotspot and repeating border over the volume. If every kernel value is equal, look at the heightmap, whether the hotspot is outside the volume. If so, decrement the new volume value. Else, increment. Stop this process when nothing changed anymore. So after the first run, our volume looks like this:

Repeat, now it looks like this:

Repeat:

Repeat:

-> Ou, nothing changed, no repeatition anymore. Looks like a 2D volume, or?

Procedural Terrain Generation

A Perlin Noise source. http://cs.nyu.edu/~perlin/noise/

More CSG base primitives

More shapes:

• http://www.math.hu-berlin.de/~filler/3D/flaechen.html
• http://www.singsurf.org/singsurf/impsurfhelp.html
• http://www.singsurf.org/parade/
• http://wims.unice.fr/~xiao/gallery/

De-/Serialize the Chunk Tree

As the loading time can be significant, an option would be nice to throw the generated tree with all its triangles to the disc and load it again. This way, this serialization could be delivered with the product or generated just once if too big for this. Might be also an idea to just serialize the DualCells?

Affine CSG

Beside scaling, there could be rotation and translation. Or any 4D matrix? Depends on whether it's possible to get the inverse of any 4D matrix in Ogre.

Parallax Occlusion Mapping

This would be really cool.
http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/a-closer-look-at-parallax-occlusion-mapping-r2325
http://developer.amd.com/media/gpu_assets/Tatarchuk-ParallaxOcclusionMapping-Sketch-print.pdf

Is this maybe an already working CG implementation?
http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Offset+Bump+Ambient+Lightmap&structure=Cookbook

And: The currently used textures already offer an heightmap! So this one could be actually being fast implemented?