I've been working on something like this on-and-off (mainly off) for a while. I was able to get quite good performance by rendering a standard cube mesh with instancing, but I never got around to adding more obvious techniques like frustum and occlusion culling.

I've no idea how Minecraft achieve such speeds - culling faces per cube seems like a huge task, as does joining adjacent strips. Especially considering the amount of cubes that appear to be drawn at a time:



[Edited by - Barguast on April 29, 2010 6:03:43 AM]

I've been working on my own voxel engine for a few years now (http://www.thermite3d.org), and it quite happily handles volumes up to 512x512x512 voxels. A lot of the comments made so far make good sense but I'll summerise what I do.

Firstly, I break the world down into chunks of somewhere between 16x16x16 and 64x64x64 (the best chunk size depends of several factors). Next, I generate a mesh for each of these chunks. I actually use the Marching Cubes algorithm but this doesn't really matter - any algorithm for generating a mesh from the volume data is fine. I then upload these meshes to the GPU and use frustrum culling to decide what to draw. I can also send them to the physics engine for simulation.

As mentioned, the mesh data for a chunk only needs to be updated when the corresponding part of the volume data is changed. Most changes are fairly localised (explosions and stuff) so this helps keep down the amout of mesh regeneration.

I've also recently been experimenting with combining adjacent faces. There is a lot of research and information on the internet about 'mesh decimation' and 'mesh simplification'.

You can find more information in the following forum thread: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=27394

I also wrote an article called 'Volumetric Representation of Virtual Environments' which is Chapter 3 of the book 'Game Engine Gems'. There's a lot more detail in there.

Indeed, chunking seems to be the way to go. I wrote a very basic voxel tessellator (lacking combining adjacent faces which I'm not sure I actually want). The tessellator produces a 16x16 voxel triangle mesh.

I'm able to draw 4096 (the number as shown in my screenshot above) of these chunks at 10 FPS (without instancing). All the chunks are the same at the moment so I don't know how representative of actual performance this is, but this is without frustum or occlusion culling and - perhaps most significant of all, with an almost 'full' chunk (whereas Minecraft is mostly empty space).

I have a feeling that a few basic optimisations, and perhaps chunk-based LOD will yield some good results.

I'll have an experiment with a more realistic test tomorrow and see if it makes a difference. Thanks for you tips - and hopefully you're helping the OP too. (Sorry for the hijack :p)

The idea I had regarding chunk-based LOD was simply to double the size of the blocks and sample based on the most common block type within the larger block.

For example, at the highest LOD, my chunks are 32x32x32 and block size is 1x1x1. At the next one, they are 16x16x16, but the block size is 2x2x2 (which will be of the type most according in that 2x2x2 block). For example, if there are 5 solid blocks, it will be solid. If there are less, it will be air (not there).

Your quad merging looks quite affective. I wonder how this will affect tiling, though? I'm sure it'll speed things up to a degree, but I wouldn't want to lose the ability to wrap textures properly since (I think?) an implementation like this is dependent on using a texture atlas. Unless there is another way?

I hate to say it, but you've only done the easy bit. You geometry is now full of "T" junctions and these will show up as annoying glimmers when you start putting textures on.

For a solid display, you just cannot have a vertex resting in the middle of a line between two others - you have to stitch them such that any lines passing near or through a vertex actually weld to it properly.