An introduction and some questions.

[PolyVox]

Hi Guys,

I just wanted to introduce myself and ask a couple of questions about integrating Bullet with my work. I've come over from the Ogre3D forums where I've been working one using volumetric representations (voxels) as a way of doing fully destructible environments. I store the world as a volume (which is easy to modify on the fly) and convert it to a polygon mesh for rendering. You can see more details here:

http://www.ogre3d.org/phpBB2/viewtopic.php?t=27394

I'm now interested in adding rigid body physics so that objects can interact with the world. I would also like pieces of the world which get disconnected during the destruction to be able to fall down, bounce around, etc. At the moment the world is a little too static, and I'm considering Bullet as the physics engine to help with that

Now, I'm aware there is already some work on integrating Bullet with Ogre and over the next couple of weeks I'll try to get that working. But first I'm more interested on you thoughts on how practical it is as to be honest I don't have much experience with physics.

So, I assume Bullet makes some distinction between 'world' geometry which never moves and 'object' geometry for things like characters. My first question then is 'how big can this world geometry be?' The marching cubes algorithm I use to convert the volume to a mesh creates a lot of polygons - would 1 million polygons be too many? I suspect it would, in which case I can use lover levels-of-detail for the physics. Each LOD would be 1/8 the size of the one above - how many polygons would Bullet handle for static geometry while remaining interactive?

Secondly, what kind of internal structures does Bullet need, and how long do they take to build? For rendering I'm just generating vertex and index lists, but for physics you must need more connectivity information and the like. Will Bullet build it's desired structures from vertex and index lists or I must do something myself? How long will it take? Obviously my world is changing, so I need to rebuild these things on the fly.

Lastly, I assume Bullet provides some kind of 'particle' type which is much simpler than rigid bodies. Now, one of the nice things about having volumetric data is that collision detection become very easy - it's simply a case of looking up a given position in the volume to determine if it's occupied. Might it be possible for me to provide a custom collision detection function for particles which could exploit this fact?

Ok, that will do for the moment Sorry if I've asked anything daft - I'm not a physics expert. Thanks for any feedback!

[Erwin Coumans]

How many polygons would Bullet handle for static geometry while remaining interactive?

It depends on the density of triangles (how many triangles overlap with a typical moving object?). One million triangles should theoretically work, but so far the most complex static triangle meshes I've seen used in Bullet are about 100.000 triangles.

Secondly, what kind of internal structures does Bullet need, and how long do they take to build? For rendering I'm just generating vertex and index lists, but for physics you must need more connectivity information and the like. Will Bullet build it's desired structures from vertex and index lists or I must do something myself? How long will it take? Obviously my world is changing, so I need to rebuild these things on the fly.

Bullet allows you to use your vertex and index lists directly. Either re-use the graphics data using btStridingMeshInterface, or duplicate it using the btTriangleMesh. Bullet btBvhTriangleMeshShape (with quantization) builds a compressed AABB tree for static (non-moving) triangle meshes. You can build this at run-time, or serialize/deserialize it from disk. See the ConcaveDemo on doing this. Press 'g' in this demo to see deformation: the AABB tree has a refit function (refitting all AABBs) and a partialRefit for a local deformation.

Lastly, I assume Bullet provides some kind of 'particle' type which is much simpler than rigid bodies. Now, one of the nice things about having volumetric data is that collision detection become very easy - it's simply a case of looking up a given position in the volume to determine if it's occupied. Might it be possible for me to provide a custom collision detection function for particles which could exploit this fact?

Yes, you can provide and register a custom collision detection function. We can discuss further once you get things up and running.

Thanks for showing interest,
Erwin

[PolyVox]

Thanks for the quick reply! (and sorry for using the wrong forum ) It seems Bullet could be promising. I currently split the volume into blocks so that, when part of the volume changes, I only need to regenerate the surface for the modified blocks. The same principle can can be applied to the physics data, and it also means I may be able to toggle blocks as active/inactive and omit them from the physics simulation if they are out of sight.

The type of polygons existing in the mesh are also highly constrained. Most of them lie parallel with one of the axes, and those that don't lie at exactly 45 degrees to the axes (I tweak the normals to make the surface look smoother than it is). Also all the vertex coordinates are integers. If I end up writing some custom collision detection code I may be able to exploit these facts as well. But better not run before I can walk

Anyway, I guess I download the SDK and take a poke around. I'll have a look at the state of the OgreBullet bindings and see if I can get them into shape.

Thanks for your help!