btConcaveShape implementation question

[JohnJ]

(Since I rewrote my graphics engine a few times, I never got to use Bullet even though I've been planning to for over a year. Now that I'm actually starting to get into learning Bullet's structure, etc., I'm very happy so far to see how clean and simple the interface provided by Bullet is for extending collision shapes, etc. )

To enable collision on an extremely massive terrain (several million square miles), and since btHeightFieldTerrainShape won't work, I'm going to implement a custom btConcaveShape.

I have a performance question:

- For a world this large, would it help long ray tests if I separated the world into a few hundred chunks of MyConcaveShape (not the actual class name of course) objects with their own AABB's, or would this just "pollute the broadphase"?

I ask this because I'm worried that a long diagonal (non-axis-aligned) ray will create a massive bounding box which obviously would kill performance if used to query triangles.

[ola]

I use the btBvhTriangleMeshShape for my terrain system. The terrain is divided into tiles that are 4x4 km each, with one shape for each. This way I can load terrain on demand (add/remove tiles). So I'm not sure you really have to create your own concave shape, the Bvh shape is pretty fast for static objects. If you have a heightfield, you'll just have to convert it into a mesh. And, if your terrain is also a mesh that you render, you can re-use the same mesh for both collision and rendering without copying the data.

Note that if your terrain is really huge, you might have precision problems in single precision mode when you are far from the origin point. I have a complete earth globe with one meter as unit, and definitely had to use the double precision mode, even though it's slower. I don't know the exact limit in single precision mode where results start to get weird when your position values are large, but I think it's getting difficult some place between 10.000 and 100.000 units (at 100.000, the numeric "steps" are about 0.008 which means your rigid bodies will move in steps of almost 1 cm at a time).

Ola

[JohnJ]

Ok, that's kind of what I figured. Now that you mention btBvhTriangleMeshShape, it occurs to me that since the bounding box is axis aligned, for a spherical planet it will encapsulate a non-square region of the heightmap and therefore I probably wouldn't be able to come up with a much faster algorithm than btBvhTriangleMeshShape anyway. I'm glad to hear btBvhTriangleMeshShape is fast enough to load dynamically for you - especially with 4kmx4km tiles, since that would normally be something I'd be worried about.

And of course I'll be using double precision

I don't know the exact limit in single precision mode where results start to get weird when your position values are large

From my calculations, you can only maintain <=0.1mm "steps" up to 0.8 kilometers from (0,0,0). Definitely not enough for my game.

Double precision, on the other hand, can maintain <=0.1mm steps up to an incredible 450,359,962.7 kilometers in any axis from (0,0,0)