I’ve always been fascinated by physics. As a young lad I’d watch science documentaries rather than the soap operas and comedies everyone else in school seemed to watch. I actually paid attention in science classes (which probably explains why I had no girlfriend at the time, but I digress). I whooped with joy watching the Half Life 2 videos from E3 in 2003 when it was made clear that physics was a big part of the gameplay. If rendering (which is of course a branch of physics) hadn’t been even more intriguing to me, I might well have become a physics programmer.
Fast forward a decade or two – I’m writing my own game and naturally physics is a key feature. I know just enough about rigid body physics to know that writing my own physics engine is far beyond my current skill-set so I’m using a 3rd party physics engine called Bullet Physics. I won’t go into the reasons for choosing this particular engine (perhaps in another post), but here I will describe the basic concepts that rigid body physics engines all share. I think it vital to understand the basics of how a physics engine operates, even if you’re using an existing codebase as this understanding will help you use it most effectively.
Rigid Body Physics
What do I mean by “rigid body physics”? Quite simply, it is the simulation of forces such as gravity acting upon solid objects. For example, a crate falling off a ledge, a weight pushing down the end of a see-saw, a ball bouncing on the ground, a pool cue hitting a ball. This is contrary to “soft body physics” which simulates objects such as cloth or jelly.
In the real world, physics happens continuously (or does it?), but in a game we run the simulation in discrete timesteps – generally 30 or 60 times a second, often even more often than that (perhaps 120 or 180 times a second). The more frequently the simulation runs, the more accurate it tends to be, but of course there is a performance tradeoff for this. That decision is made for each individual game depending on its requirements.
Step By Step
So what does the physics engine do? Quite simply, for each simulation step, it executes the following operations:
- Apply forces (such as gravity) to the objects and move them according to their momentum.
- Detect any collisions between objects.
- Resolve the collisions.
Of course, there’s a lot of detail to each of these steps (for example, step two happens either discretely – checking only each object’s new position, or continuously by sweeping the object from its previous position to its new position), but I shan’t go into that level of detail here as it would make for an enormously long post (probably a book) and there are other people better far qualified to write that.
Objects
Whilst debate rages on about whether object oriented programming is a good thing or not, in physics everything is an object. There are three classes of physics object.
- Static – these objects do not ever move, no matter how much force is applied to them. You would use static objects for your world geometry – ground, walls, etc. Whilst technically unrealistic (even a planet can be moved with a big enough force), treating such things as completely static helps to keep the cost of the simulation down.
- Dynamic – these objects are subject to forces and move freely within the static world. They are acted upon by gravity, being hit by other objects, and so on. Examples of dynamic objects include crates, balls, rocks and grenades.
- Kinematic – these objects are explicitly moved by the game though user input, scripting or animation and the dynamic objects respond to collisions with these. You would use kinematic objects to represent the player, melee weapons, etc.
Usually, the physics engine will use what are called “Simulation Islands” in order to increase performance. What this means is that rather then simulating every dynamic object in each step, only those that are in motion, or have been touched by a kinematic object are simulated. When these dynamic objects are at rest again, they stop being simulated.
Primitives
To get the best performance and accuracy from a physics simulation it is rarely a good idea to use your render meshes as physics primitives. The physics library will provide a set of basic geometric primitives to use instead. You might model a crate using dozens of triangles, but you are best off using a single cube for the physics simulation in order to keep it fast. For accuracy, you would use a sphere to correctly model a pool ball, rather than the mesh of triangles that is being rendered as this mesh won’t roll correctly. A first person player is best simulated as a cylinder or capsule (a cylinder with rounded ends) rather than an animated character. For a car or a boat, you would use a simple convex hull. Even for world geometry you are probably best off using a simplified version of the render mesh, not only for performance reasons, but also because overly complex physics geometry can cause objects to get stuck or fall out of the world.
In conclusion, I hope this primer is valuable to someone using a physics engine for the first time.