Hey,

I'm thinking about using PolyVox in the game engine I'm developing. Looking at the interface so far I'm liking how simple it appears to be. I do however have some questions as to how to efficiently render the voxels.

Can some form of spatial partitioning (octree) be applied to cull away lots of regions quickly? From what I've seen in the examples, usually the entire volume region is used to extract to a single mesh. I suppose an Octree could then be generated based on this mesh. The other option would be to have multiple meshes by using the surface extractor for each region that correlates to a quadrant in the Octree - this might be slow though? How do other people handle culling and is there a good way to allow for dynamic modification using a spatial structure?

I'm guessing Hardware Occlusion Culling could be achieved but has anyone tried it with PolyVox?


Thanks

Add: Sorry wasn't talking about anything relating to your question. The cubic extractor only extracts visible surfaces for a region you specify. So let's say you have a 1024x1024x128 terrain. You usually break this down into 32x32x32 chunks and extract those. Now in the normal usage case, a large part of this volume may consist of homogenous blocks, so the engine won't extract mesh from any of that. It will only extract what is visible, blocks that are exposed to air.
....
Well I thought about doing it using octree before but in the end I decided that it wasn't worth it given the tradeoff between culling and speed of access to each voxel element and neighboring elements. With an octree to access an neighbor it's O(log_base8 N), which in practice is slower than O(1) which is what you get with the current scheme. With that said I know BigVolume does some block management behind the scene but most of the time it works with blocks that is directly accessible. Is there assumption still correct?

I'm currently adding a new volume class which will page into a fixed size array of blocks and that can still do compression. I'm doing this because I need it, it may be slightly faster than the current big volume scheme.

Either way it's a tradeoff if you go with an octree.

So are you saying it would probably be faster to simply use the surface extractor to create mesh chunks with which you would just do basic frustum cull on? Rather then trying to wrap it all into an Octree?

In terms of real-time modification, do you have any tips relating to the updating of vertex/index buffers? Eg. each time you extract a mesh when it's been modified, the VB and IB's will need to be updated - but this would be pretty slow if they were simply destroyed and created each time.

I use Ogre and it does frustum culling based on AABB of the chunks. In my current setup I use Ogre manual object and I naively create and destroy these each time they're modified. It's not that slow for me. It's working for me but the plan is to change it in the future to reuse rather than create / destroy. (Some latest screens from my game: http://fdastero.tumblr.com/tagged/screens ; in the middle of a refactor right now).

For occlusion culling I'm planning to use hardware occlusion culling. I plan to adapt the coherent hierarchy culling paper (CHC and CHC+). For a cube games you can probably just interleave the occlusion querying for the AABB of each chunks and then based on the results set chunks to invisible to your scene graph traversal system and be done with it. This will work great when you are underground and inside gives and you don't have to go all out modifying your scene graph to support this like CHC.

Personally I've just been usng a flat grid structure so far. I take a single volume and generate a number of meshes corresponding to regions of 32x32x32 (though you may want to use a different size). Each of these seperate meshes get culled against the frustum and that's all. It would certainly be interesting to investigate more elaborate schemes (and an octree seems like a natural choice) but I simply haven't had the need for it yet.

Same applies to the vertex/index buffers - I've thought of fancy schemes in my head but simply overwriting the previous data seems pretty fast for now.

I do think hardware occlusion queries would be worth investigating, though it depends on your environment of course.

I guess I'll just have to give it a go and see what the performance is like for large terrain.

How do you guarantee that when you modify a 32x32x32 region that it will have the same amount of vertices and indices? Surely you could have more after modification than what you originally created the VB/IB to store which means you would have to recreate it fully rather than overwriting, correct?

Yeah, people have worried about this in the past but I don't think it's really an issue. I think a modern GPU can transfer hundreds of megabytes per second to the GPU, and a mesh from a 32x32x32 region is probably just a few tens of kilobytes. It really doesn't take any time.



This is correct, there is no guarentee. But how you handle this is up to you - you could have one huge vertex buffer which you manage manually, a set of different size vertex buffers where you choose the smallest one you can, or just allocate on the fly. Standard memory management techniques apply really, but I consider it outside the scope of PolyVox to dictate how you render the mesh it provides. That might sound like an excuse, but it's really just providing you with flexibility