Finite collision world - is this a showstopper??

[moonshine]

The "Hello World" example contains these lines:

btVector3 worldAabbMin(-10000,-10000,-10000);
btVector3 worldAabbMax(10000,10000,10000);

This restricts the collision detection to a cube of size 20km.

This is a major problem if you are simulating collision activity on a vessel that is continually travelling forwards.
For example, a vessel starting at the origin and moving at 10m/s would exit the collision world after 1000 seconds, or ~17 minutes.
(Also, it looks like having a finite collision world is going to make space simulators impossible).

It is important that the vessel continues to move forwards in the simulation.

Staying with the terrestrial example, is there a way for the vessel to "carry the collision world" along with it so it stays centered on the vessel?
E.g. could I simply update the collision world extents by calling worldAabbMin() and worldAabbMax() every now and then, so that the vessel remains in the middle of the collision world?

[ola]

I recommend you use the btDbvtBroadpase instead of btAxisSweep3. That one does not have the fixed world limits like you describe and it performs really well.

If you want a world larger than 20 km you will get precision problems using the default Bullet configuration which uses single precision floats. You can compile it with double precision instead which gives you enough precision to simulate whole planets and even a solar system. But it comes at a performance cost. I use double precision myself and it's ok for my application (which is PC only), just don't expect to stack as many boxes and such as you can with single precision.

You could also use single precision and move your applications origo at some interval, as you suggest. It would look like, when your vessel moves further than 10 km away from your current origo, translate it back to the origo, and use the same translation on all other items in the simulation. Items further than 10 km away from the vessel should be removed. Keep track of where this movable origo is, in a double precision position coordinate, so that you can calculate your vessel's absolute position.

Cheers,
Ola

[Sorlaize]

There are other ways of doing it, for example simulate the world and then offset all of your world's objects by the inverse translation that your main object moved, so that it actually stays at the same position but things move around it, in and out of the physics world. I don't know how well this would actually work but it depends on your specific problem.

Another option is having multiple world instances at different locations:

btVector3 worldAabbMin(10000,-10000,-10000);
btVector3 worldAabbMax(30000,10000,10000);

You could visualize them as a grid of cubes and highlight the active world in a different colour for testing. Again it depends on your problem. Using the btDbvtBroadpase might be better though.

[moonshine]

Ok, looks like the solution is to use btDbvtBroadpase instead of btAxisSweep3.
Thanks everyone!