I have been looking at the Thermite Engine source and find the SurfacePatchRenderable, VolumeManager, and Volume Resource files very interesting. It looks like they have a great way of organizing and rendering chunks of landscape.

I am considering using a form of these files to manage and render my voxel landscape. However I am having trouble understand one part of their implementation.

I am confused how to connect them to OGRE. They obviously use the renderableOperation class, but I can't seem to find the place in the thermite code where they are actually rendered.

If someone could help me understand how I can connect these files to OGRE. I would be very grateful. At least point me towards the place in the Thermite where they are rendered so I can trace the function calls.

Thank you for your help, this is a great forum. Its hard to find support this good for a library.

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

I wouldn't assume that - I just pieced this together by looking at examples in the Ogre3D docs and wiki. I did it a while ago so I'm actually a little hazy on how it works

In the Ogre docs you should have a look at the Renderable class (which SurfacePatchRenderable is derived from) and also the RenderOperation class (which SurfacePatchRenderable contains an instance of).

The SurfacePatchRenderable::buildRenderOperationFrom(...) functions take a PolyVox mesh and builds an Ogre::RenderOperation by working directly with the Ogre::HardwareBuffer. These functions could more or less copy the data acrross, but actually they each have an extra trick:

1) The cubic version packs the material into the 'w' component of the vertex, meaning the whole vertex data fits into a single position stream. This requires a custom vertex shader to avoid messing up the projection.

2) The marching cubes version inserts some extra triangles which are used for blending between materials.

These tricks are not essential (or even a good idea!) - they are just ideas I was playing with. For the actual rendering I think '_updateRenderQueue()' is the important function to have a look at. Check in the Ogre docs to see how it fits together.

You should also look at the ManualObject class which provides an easier interface - I was using that initially before I got brave

It sounds like my confusion is a lack of understanding of the Ogre3D engine. I didn't realize you had used so many Ogre Features. I need to go study the engine a bit more. The tips you gave should help me understand the code.

The main reason I was interested in using this code relates to the comment you made.



I know this is one of the weaknesses of the marching cubes algorithm. When connecting different chunks of voxel data, one must add additional triangles to cover gaps that occur between edges of different chunks.

It sounds like surfacePatchRenderable solves this problem, and I thought that would save me some time.

If you think there could be problems with this method of rendering, what general principles would you suggest when trying to keep track of many chunks of voxel data and blending the edges inbetween chunks?

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

No, this is a seperate issue. What I'm handling here is if a single triangle has a different material at each vertex. In this case I duplicate the triangle and render it three times, it's not related to LOD of chunks.

As for the chunks, the will align perfectly unless you generate then at different resolutions (for LOD). So if you have the five chunks near the camera at high LOD and the next five at a lower LOD there could be a gap. I've not done much work here - personally I would start fixing it by rendering both high and low LOD for the transition zone. This should fix it but at the expense of rendering a bit more than you need to. More advanced approaches include the 'TransVoxel' algorithm which isn't implemented in PolyVox.