Creating the Overgrowth physics engine news

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. Here is what the Lugaru ragdoll looked like when held up by some stick-ropes:

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. Here is a picture of some of the ligament constraints in my musculoskeletal simulation:

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. This is a stress test of ODE physics I did in an older version of Phoenix (it has some fancy shadows because it is a tech demo, and I didn't care about compatibility and scaling issues):

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?
(permalink)

Track us on ModDB (see our cool page)
and also join:
- Facebook
- Steam
- Twitter
- YouTube