Choosing a correct collisionshape for a voxel engine

Question

I am building a voxel engine on Ogre with bullet as a physics engine.

I separated my blocks into chunks to help batch together render calls.

At the moment, each chunk's physics is handled by a btBvhTriangleMeshShape that is constructed through the vertices and indices.

Each time the user breaks a voxel, I modify the vertex and index array and construct a new btBvhTriangleMeshShape.

Unfortunately, because btBvhTriangleMeshShape has to recreate an optimizedBVH each time it is created, this becomes quite slow, taking several seconds each time the user breaks a block.

I've alternatively tried using a btConvexTriangleMeshShape, but the broadphase collision detection now becomes very low performance dropping the fps to single digits if the player is near the blocks.

What is the proper collisionshape to choose?

Answer 1

Ive decided to use compoundshape and construct boxcollisionshapes for each block. I've done some optimization to only build collisionshapes for visible blocks.

As requested, here's some more information:

1. For each Chunk I create a OgreBulletCollisions::CompoundCollisionShape

2. For each visible Block inside each Chunk I construct a OgreBulletCollisions::BoxCollisionShape of the proper size.

3. Next I call CompoundCollisionShape's addChildShape function to add the BoxCollisionShape to the CompoundCollisionShape.

4. When all the box shapes are added I create a RigidBody out of the CompoundCollisionShape

As for the optimization:

1. I build the chunk with Ogre3d's ManualObject

2. I iterate through every block inside a chunk and then iterate through all of the 6 sides of the block

3. For each side, I check if there's a block adjacent to that side. If so, that means the side is obscured and do not need to be rendered.

4. If all 6 sides of a block are all obscured, then the block need not have a collision shape attached to it.

5. Recalculate as necessary if chunks are modified.

Answer 2

So couple of things to keep in mind here, typically physics engines are built with the assumption that objects are not added/removed as much as would happen with voxel engines. Not only do you have to update when they change the terrain, but you are going to be constantly removing/adding chunks as they walk around the world. The other thing to consider is that the physics engine keeps it's own copy of all the shapes in an oct-tree. Meaning you're going to have two copies of all the geometry floating around in memory, which can be expensive.

Also, with all the adding and removing you'll be doing, you have to consider that octtrees are not so great at the adding and removing part. They are great for spatial lookups, but slower to update. Now it's perfectly possible to still do all of this, but these are some good things to keep in mind.