Game Engines, part 4

Physics
Games today require physics. I think it's safe to say that only a handful of genres are safe from this now. But never fear. Although messing with physics has been one of the more difficult things I've done, in many ways it has been the most fun and rewarding. In a 3D environment, humans like to see things move the way they're supposed to, enemies fall and collapse realistically, and objects explode with real-time shrapnel. It's fun to look at, and it changes the way a game is played.

There are a great deal of physics engines out there. This is one field where proprietary, pay-to-use engines practically don't exist. While they're out there, they're not market-domineering like in other fields, and if they are sold, they normally are packaged with a graphics engine. You might have heard of Newton, the engine used in Portal, Half Life 2, Penumbra, and a ton of other physics-oriented games. While not open source, it's free to use as long as you show off the Newton logo on your product. It works in Linux, Mac and Windows.

Of course, you've probably guessed that I don't recommend it. Closed source software is not as "yours" as open source. You cannot modify it or look to see how it works. So I suggest any of many free alternatives: ODE, Bullet, Squirrel, and a billion more. I recommend Bullet. It's being used with the Blender game engine, and is picking up popularity very fast. It's also continuously updated.



Going into physics, I was a bit unsure about one thing. I knew that I had meshes in my program, and they draw to the screen based on their location and the camera's location. I got how that worked. But how was the physics engine supposed to look at the picture? Do I have to use mesh file types that work for both libraries? And how does the physics engine forcefully move objects in my 3D world?

It took me a bit to figure it out on my own, so hopefully this explanation will be helpful. It works like your average kitchen plastic wrap. Say you have a whiffle ball that you wrap up in that stuff; what shape is the wrapping after you've completely enclosed the object? Essentially, it's a sphere. In other words, it is not exactly the same as the object it is covering, but it outlines it. The holes aren't considered, unless you need them to be for some reason.

Because of this, physics bodies are less complex than the meshes they represent. Most physics engines use this trick ( among many others ) to minimize their cost. This is important, because every time you give an object physics you are basically cloning it in the same scene. This can take more memory, but not a whole lot of extra processing. After all, the invisible "wrapping" mesh is not being drawn, not being textured, not being shaded, and it's got significantly fewer polygons than the mesh it's connected to.

For Bullet, every dynamic object has a STATE. That state is its location and rotation. Every time you "step" the scene, which means applying about half a second worth of physics for a frame, or so, those states change. Overload the state class, edit it to contain a link to the mesh object, and have it move the mesh whenever IT moves. Thus, the wrapping tugs its mesh along with it, giving the illusion that the object itself has physics.


Didn't I say it was all an illusion?