http://blog.wolfire.com/2009/05/creating-the-overgrowth-physics-engine/
By David on May 20th, 2009
Lugaru physics
Ragdoll physics played an integral role in the gameplay of Lugaru – much of the strategy consisted of arranging fights so that Turner falls on soft surfaces and his opponents crash into hard ones. The ragdoll physics in Lugaru were based on Newtonian particles connected by rigid stick constraints, as described in this paper. This method worked to simulate basic physics efficiently and robustly. I created a physics editor that allowed me to load a model, quickly set up its stick skeleton, and then simulate it and test it out.
False starts
This method could not handle hinge joints or rigid body collisions, so I looked into some alternatives for Overgrowth. I tried a number of different ideas, from an extended point-constraint model based on the old Lugaru approach, to a medically correct musculoskeletal simulation. These ideas turned out to be wrong for Overgrowth — the point-constraint model could not be efficiently extended to traditional rigid body primitives, and the musculoskeletal simulation was too complex to be stable with large timesteps. They weren’t a complete loss however — I learned a lot about physics simulation, and my point-constraint work ended up providing the foundation for the ragdoll physics in Cube 2: Sauerbraten, a great open-source FPS game.
Middleware libraries
I knew that we would need basic rigid body collision detection and response in Overgrowth, and I didn’t want to try to reinvent that wheel myself. Middleware libraries I looked at included Newton, ODE, Bullet, Physx, and Havok, and chose ODE for several reasons. First, it is free and open-source — this is important because it means I can go in and make any changes we need for Overgrowth. Second, it is well-documented and well-tested: it was used in big projects like Stalker, Titan Quest, and Elebits. On the other hand, while Bullet is not quite as mature as ODE yet, it is improving faster, and may be better in a couple years.
We also looked into Euphoria, but not only is that not a physics engine, it’s not even a product — you basically hire their programming team to work on incorporating dynamic physics animation into your engine. This is extremely expensive, and not necessary when we can implement the same techniques ourselves.
Beyond middleware
While middleware physics engines handle basic collision detection and response, there is a lot left that they don’t handle. They only do one thing — when they are passed a set of rigid bodies, they determine what happens in the next timestep according to the simulation rules. It is up to us to figure out what rigid bodies to pass in, and what to do with the simulation results (apply damage, create sound and particle effects, etc.). My next step in the physics engine is to create a materials system that can handle collisions between different surfaces: a metal sword falling on a stone block should be a different kind of collision than a body falling into snow. This feature was already built-in to Lugaru — are there any new features you would like to see in the Overgrowth physics engine?