Converting loaded Static Mesh to a Convex Hull (Or Similar).

[tmason]

Hello,

I have more of a best practices kind of question. So I have a working Bullet Physics implementation with walking camera, dynamically insertable/deletable objects like boxes, and a dynamically loaded mesh from file.

So far so good; basically I can load a static mesh and walk through the environment with full physics.

Now, for certain mesh that I identify, like a door for example, I would like to turn that mesh from a static mesh into an object I can interact with (move around, reacts to physics, etc.)

Currently, these sort of objects I am loading in as static mesh (via a btBvhTriangleMeshShape class).

The question is if there is a possibility to convert such a shape, after being loaded, into a dynamic object while it is attached to the dynamics world.

For example, I click on an object (via a RayTest, collision callback) and based on my defined callback convert the btBvhTriangleMeshShape into a ConvexHull shape (or whatever works) and then I can move the clicked object around, etc.

I hope this question makes sense.

Thank you for your time.

[c6burns]

In my opinion, for something like this you are going to end up removing the original body from the world and adding another body in its place.

[tmason]

In my opinion, for something like this you are going to end up removing the original body from the world and adding another body in its place.

I see; my assumption is that you can copy the motion state, scaling, etc. from the original body into my animated body.

Correct?

[drleviathan]

The world has objects (btCollisionObject or btRigidBody) each of which has a shape. The object determines the dynamic properties, not the shape -- the shape is just geometry.

When converting a static object to a dynamic one (or when swapping in a significantly different shape) you must remove the object from the btDynamicsWorld, change its parameters/shape/etc, and then reinsert it. This is because there are several internal lists and data structures that cache the state of the world and assume that shapes are not swapped out from under their noses. The CPU cost of an object's removal/reinsertion depends on its size and the total number of objects in the world -- small objects in a sparse simulation can be swapped out quickly, large objects in crowded simulations can take several milliseconds to swap.

If your door is part of one big mesh and you want to make it dynamic while keeping the rest of the mesh static then you'd have to remove the btCollisionObject that has the big mesh, compute two new shapes: one for the mesh without the door and another for just the door, give the first shape back to the old btCollisionObject and add it back into the world, and then add a new dynamic btRigidBody with just the door shape and add that to the world.

The cost of that operation can be higher than you'd like to pay, depending on your simulation. If you know the door may become interactive then the best practice would be to split it out at the start and add it as its own static or kinematic object so that when it needs to move you don't need to remove/reinsert the rest of the landscape. This is why many games have limited interactivity: only certain objects can be moved and certain walls can be knocked down -- it is much cheaper to treat the whole landscape as one truly static object. If the interactivity is not important for the game mechanics then it is optimized out.