Best collision shape for voxel terrain?

[connerk]

I'm building a 3D flight game (http://degreesgame.com) that uses a voxel structure for the environment … think Minecraft, except the environment can't be modified. I want to create an accurate collision structure when compiling my levels, then load them up at runtime.

Essentially what I'd like is a compound shape made of lots of AABBs. I've got some plans for decomposing the voxel environment and deriving those boxes. So assuming I can get that far on my own, what's the best way to hand this off to Bullet? I could build a btCompoundShape with a set of btBoxShapes, but that seems like I'd be missing an opportunity to speed it up, since those classes are more appropriate to a moving object. On the other hand, deriving a static triangle mesh seems excessive in the other direction. Performance is my main concern since this is an iOS game.

[codetiger]

Am not an expert, but wanted to reply: "The game looks wooowww.".

Meanwhile, I am wondering if you can calculate all islands of objects and build a convexhull shape for each.

[connerk]

Am not an expert, but wanted to reply: "The game looks wooowww.".

Meanwhile, I am wondering if you can calculate all islands of objects and build a convexhull shape for each.

Thanks so much! Yeah, I can get convex hulls, and I do do that for moving objects, but there are also some complex environments that I need to fly inside and through, like this one:



So I'm looking for a more general solution.

[connerk]

An update: So far I've found that a compound shape with many btBoxShapes works OK. On an iPad mini I get fine performance with several thousand boxes in a single compound shape. But leaving these boxes independent is prohibitively expensive, I guess because it's so much more work in the broadphase.

From profiling, it looks like I can get better performance from the compound collision algorithm if I decrease the number of box shapes constituting the compound shape. So it appears to be better if I let them overlap and cross over one another.

But I suspect that this is still a lot more work than should be left for individual collision checks. The compound shape uses a BVH for its children, but walking it takes a lot of my running time (and it's made slightly more expensive when I let the boxes overlap, but the benefit of having fewer boxes outweighs the cost of having larger boxes). So what I'm planning to try next is to subdivide my levels into fixed-size cubic cells, make a compound shape for each, and try to balance the number of static compound shapes in the broadphase against the number of child boxes in each shape.

I will probably also try instantiating these collections of boxes as scaled triangle mesh objects, with a single cube mesh. I don't know whether that will end up being more or less expensive during the narrow phase, but any broadphase improvements I make ought to hold up since the AABBs will be the same (right?).