• entries
743
1924
• views
582953

# Grappling with Bullet Physics

1455 views

Well, Bullet Physics turns out to be, um, quirky, to say the least. Not that I'm complaining, its amazingly well written and stable and very easy to get it set up to do the basic convex shapes rolling around a level, but once you step beyond that, the documentation is often wrong and parameter names can be a little misleading

What I have found very easy, though, is to use smaller subsystems of Bullet on their own. So in the image above, all of the shapes except the player are Bullet btRigidBodies under the hood, and feeding their positions back to the scene after allowing Bullet's stepSimulation to simulate their movement.

But the player itself is not even added to the world. I'm using a combination of a btCapsuleShape, Bullet's broadphase and its GJK implementation to do the intersection tests and generate the mimimum separation vector. Works really well and is a hell of a lot more stable than my own GJK implementation.

I guess as well, when I come to start testing ray casting, I'll be able to ray cast against any convex shape, rather than my own implementation which was limited to ray casting against polyhedrons.

My physics interface, which wraps Bullet up, looks a bit like this at the moment:

class Physics
{
public:

Physics();
~Physics();

Body *createBody(Shape *shape, const Vec3 &pos, float mass);
void update(float delta);

ConvexResult convexIntersection(const Shape &shape1, const Matrix &transform1, const Shape &shape2, const Matrix &transform2);
uint bodyCount() const; const Body &body(uint index) const;
};

Body is a wrapper around btRigidBody and Shape wraps btConvexShape, but it also stores some extra information, like the face information for polyhedrons for example, useful for debug drawing and lost once it is handed over to Bullet as a btConvexHull.

Obviously doing a lot of switching between Vec3 (typedef for D3DXVECTOR3) and btVector3 and Matrix (D3DXMATRIX) and btTransform, but have some inline methods for the former and only doing the latter when needs must, so its nice to be able to use the standard Vec2, Vec3 and Matrix types throughout the whole codebase apart from in the internals of Physics, Shape and Body.

Raycasting with Bullet looks very easy to set up, so once I have that, I'll have all the tools available to implement the character controller I had working with my own custom physics, but now of course I'll have the wonderful option of being able to hand objects over to Bullet when I want them physically simulated, and handle them myself when I don't, which gives me the very best of both worlds.

The specific example that led me to this approach was thinking down the road about rag dolls for dead things. All(!) I'll need to do is come up with a way to a) generate a physics rag doll from my imported Skeleton structure and b) transform between the Bullet rag doll shapes and the matrix palette representing a pose of the Skeleton, and in theory I should be able to have a generic die() method, that will make any imported model with a rig turn into a rag doll and fall over in the environment.

But I'm sure there are a great deal more possibilities handing over to Bullet for different things. We shall see.

I'm an odd one in that I'm never too comfortable using a library unless I've had a really good go at implementing it myself. Years ago, when I first got into Bullet and Box2D, I had absolutely no idea what was going on under the hood. I don't pretend to be capable now of implementing a 3D physics engine like Bullet, but having implemented SAT and GJK myself and built a character controller around these concepts, I'm far more comfortable now using Bullet to do the heavy lifting.

So ray casting next, then push on with getting the capsule character controller working. Thanks for stopping by.

There are no comments to display.

## Create an account

Register a new account