Bullet in large worlds

[Leadwerks]

Hi, I am considering Bullet for a new project. I am currently using Newton Dynamics.

1. Can Bullet support large worlds beyond the limits of 32-bit float precision? Is this performed by using 64-bit floats, or some other means? Is there some kind of streaming mechanism I should read up on?

2. Does Bullet have any way to support large numbers of repeating static objects? I have some scenes with several million trees, each of which has collision. Is there a way to create static instances of objects where Bullet will just store a 4x4 matrix, instead of all the overhead of an entire rigid body object, so that the memory consumption is kept to a minimum?

Here's an example of what I am working with. Every single tree, even in the distance, can be collided with:
http://www.youtube.com/watch?v=xaiTw5RuG84

Thanks.

[Dragonlord]

Concerning 1 bullet can be compiled to use double instead of float. Works fine in my project. Just add the proper define flag to the command line. I don't know it out of my mind but you'll find the symbol to set in btScalar.

[Erwin Coumans]

Bullet has been used in large streaming games. There are many things that help support for large worlds. Use the btDbvtBroadphase, that helps performance of adding/removing batches of objects.

1. Can Bullet support large worlds beyond the limits of 32-bit float precision?

Yes, you can indeed use double precision build. If you use cmake-gui, just select the double precision option. It can be combined with both 32bit or 64bit builds.

Does Bullet have any way to support large numbers of repeating static objects?

Yes, there are various ways to optimize for large number of objects. For example, you can combine hundreds or thousands of trees as child shapes of btCompoundShape. You can add or remove child shapes from a compound shape. Another option is to add the trees as triangle meshes in several large btBvhTriangleMeshShape. In huge worlds, you have to experiment how partition the trees into multiple btCompoundShape or multiple bBvhTriangleMeshShape.

There is no specific streaming code, that is left for the developer. Of course you could use the Bullet .bullet serialization to load new parts of the world.

Just let us know if you need more help,
Thanks,
Erwin

[Leadwerks]

Creating a triangle mesh of unique geometry is not an option for this number of instances. Let's say the instanced shape would be 100 triangles and 100 vertices, just to pick a number. Each vertex is 12 bytes. Each triangle is 2 bytes. So each instance consumes 1400 ((12+2)*100) bytes, instead of the 64 bytes you really only need for the 4x4 matrix.

Adding 3 million instances into a unique triangle mesh would then require 4 gb of memory. If only 64 bytes were used per instance, it would only require 183 mb of memory.

1. Now that I have explained the issue in more detail, can you please comment on this again?

2. Regarding the .bullet file serialization, has the format changed between versions in the past, and were the SDK versions capable of loading old versions of the serialization format? This was a major problem in the past when I relied on this feature with another physics SDK.

[Erwin Coumans]

Creating a triangle mesh of unique geometry is not an option for this number of instances. Let's say the instanced shape would be 100 triangles and 100 vertices, just to pick a number. Each vertex is 12 bytes. Each triangle is 2 bytes. So each instance consumes 1400 ((12+2)*100) bytes, instead of the 64 bytes you really only need for the 4x4 matrix.

Adding 3 million instances into a unique triangle mesh would then require 4 gb of memory. If only 64 bytes were used per instance, it would only require 183 mb of memory.

1. Now that I have explained the issue in more detail, can you please comment on this again?

Instancing trees as child shapes in a btCompoundShape should deal with this case. It is likely good to add hundreds/thousands of trees in a btCompoundShape, and stream in/out those btCompoundShape. If this isn't suitable, we can search for a custom solution.

2. Regarding the .bullet file serialization, has the format changed between versions in the past, and were the SDK versions capable of loading old versions of the serialization format? This was a major problem in the past when I relied on this feature with another physics SDK.

The .bullet file format is forward and backwards compatible, similar to the Blender .blend format. We added members to structures and introduce new structures between SDK versions. Furthermore, the serialization is compatible across 32bit/64bit, little/big endian platforms. Unlike other physics SDK (Havok/PhysX/Newton etc) Bullet is open source, giving you more control over the implementation and data.

Thanks,
Erwin

[Leadwerks]

Thanks, that's what I was looking for.