Learning to Live With Physical Limitations

For over half a year now I’ve been tinkering away at my engine, hoping to create some amazing “Dawn of the Dead Theft Auto” game with hundreds of onscreen zombies interacting with thousands of physical objects…  To achieve this I’ve probably tracked down every managed physics engine/demo/snippet in existence, and what I’ve come to realize is that my time would have been better spent setting unicorn traps.  The fact of the matter is that XNA on the Xbox360 could never handle a simulation this complex unless the invading zombie horde was taking a siesta… or we were willing to sacrifice a bit of realism.

Thinking Last-Gen

While XNA is able to harness nearly all of the Xbox360′s GPU goodness, for reasons I won’t get into here we need to treat the CPU more like a Dreamcast.  So we need to ask ourselves if we want a small-scale realistic game, or a large-scale fun game?  If you’re shooting for the former, get the latest copy of JigLibX and make your life easy… If you belong to my unlucky camp and wish to make a large physics-heavy game, be prepared to write your own engine or think up a different game.

Learn From My Mistakes

While the physics in Dead Shift are far from complete, they’ve shown enough promise that I would like to share some of the things I’ve learned the hard way…

• Verlet Physics are no replacement for Rigid Body Dynamics.  Verlet systems may seem easy to design, but they are hard to control, hard to stabilize, and the countless constraints required will kill your performance anyway.
• Forget about fancy contact resolution, shock propagation, stacking, etc.  When you have a mind-blowingly fast engine, you can think about adding these things.
• You can approximate basically any shape with a series of spheres.  They’re easy to move around, they’re easy to test for collisions with, and you don’t have to worry much about coordinate spaces and costly matrix multiplications.
• KD-Trees are easier to implement than Octrees, and with a decent SAH (Surface Area Heuristic) they can be much faster too!
• Avoid building/clearing temporary Lists at all costs.  Have your collision detection test-as-you-traverse to avoid building lists of polygons or nodes.
• Split up work on multiple cores anywhere you can!
• Research XNA’s specific performance pitfalls on the 360.  Learn everything you can about the Garbage Collector, avoiding call-by-value functions, manual inlining, etc.
• Be prepared to lose sleep, and a bit of sanity.

Here are some resources that I’ve found useful for my little physics experiment:

• XNAMike’s port of some physics code.  I adapted an impulse response method from this sample.  [Forum Post] [Zip]
• Jacco Bikker’s explanation of KD-Trees. [Article]
• Olivier Renault’s example collision code.  Good example of OBB->OBB Separating Axis Theorem. [Forum Post] [Homepage]
• Ralph Morton’s “Icarus” physics engine.  I haven’t had much time to play with this, but it looks to be a very clean and basic engine.  No license, do what you want with it! [Forum Post] [Zip]

Edit (11/28/2009): Added some links to useful resources.