Physics Engines

Some relative newcomers to the middleware arena are physics engines. This software provides APIs to simulate the movements of 3D geometry under effects of gravity, friction, collision with other objects, and even soft body motions such as cloth. If your game needs to accurately simulate the motions of objects a physics engine might be just the ticket.

Before you read any further ask yourself if you really need a physics engine. If you only have a few simple objects that can move through your scene, such as a simple platform game, you can write this stuff yourself. Collision with simple shapes is a well published problem with relatively simple solutions. This is especially true if your objects move quickly enough to mask the effect of random rotations and they won't come to rest in piles. Perhaps having objects simply disappear after they've been hit is a good alternative to spending the annual salary of a good programmer on licensing fees.

Remember that most animations will come straight from your artists, especially character animation. Physics engines are never, ever used in the place of keyframed character animation. If you attempt to move characters around with physical forces, they'll walk around like those old CGI characters in that Dire Straits music video, Money for Nothing. Instead of simply telling a body joint to animate to a particular position and orientation over the next sequence of frames, you would have to accurately calculate the force vectors to apply to the 3D geometry making sure that any attached objects are also moved properly. Don't try it—it's a nightmare!

Instead, physics engines are used to take over after extreme forces come into play such as after a collision. A bike rider colliding into the front of a speeding bus will actually look much better under the control of a good physics system than having an artist try to keyframe it. Besides, when the rider gets crushed under the wheels of the bus the physics system will also be able to simulate the effects of the bus suspension.

Renderware has it's own physics engine—one that used to be called Mathengine, before Criterion bought them in 2002. It integrates fully with Renderware and is a natural choice if you're going to play with the Renderware solution. Another option is the Havok Game Dynamics SDK from Havok (www.havok.com). This physics and collision system is more advanced than Criterion's offering, and it includes interesting features such as vehicle SDK, where you can plug a few numbers into a little tool and create a data file for all kinds of cars and trucks. You can create a racing game with realistic steering, braking, and suspension movement in a single afternoon. Pretty impressive.

A Tale from the Pixel Mines

I was playing around with a collision system from UNC-Chapel Hill called ICOLLIDE. My task was to simulate the very clich red rubber ball bouncing up and down on a black and white checkered floor. I installed the collision library, set up my scene graph, and watched the red ball fall right through the floor. After a few more attempts and a little debugging, I realized that the ball was moving too fast. At one moment it was on one side of the floor and the next simulation step moved the ball completely to the other side of the floor avoiding any actual collision detectable by the library. When I slowed the ball down, effectively increasing the sampling rate of the simulation, the problem disappeared and I had my bouncing ball.

I thought about this phenomenon a moment, and realized that this was very similar to quantum tunneling, where a particle seems to move right through a solid object. Interesting. Then it got scary. I began to wonder if quantum tunneling was a side effect of the universe's lack of accuracy, and that perhaps the reason the speed of light is a constant is due to the fact that that is the maximum sampling speed of the Universe. It kind of makes me want to find the debugger interrupt.