This will hopefully be the final “retrospective” Robotology post, with future posts concerning what we’re currently working on rather than what we have worked on. EDIT: this post was too damn long, so it looks like it will have to be a two-parter.. hence the absolutely hilarious title.

Previously we mentioned the first of our physics tests; we also mentioned that it had shortcomings which pretty much ruled it out as a basis for physics-driven robots — it didn’t support friction, angular constraints, or motors.

By this time we had hit the end of summer 2006, which wasn’t the most productive period of time around here in terms of Robotology: aside from the usual distractions (the standard swelteringly gross Toronto summer and video game addictions — this time it was Tetris DS, which was finally satiated when Raigan attained a paltry worldwide score of 7000) we were also busy trying to secure Telefilm funding for N on XBLA, as well as talking with Microsoft. Tedious, but nevertheless needs to be done.

After the summer we found ourselves desperately broke, and still in contract limbo with Telefilm/Microsoft, so we resigned ourselves to reluctantly doing some webgame development for “quick” cash — this is actually not as bad as it sounds; we’ve worked with one particular company several times, and the producer (or whatever you call the guy you talk with who tells you what needs to get done) is really great about letting us try different stuff. We end up learning a lot.

We also did a quick job for a Toronto studio who desperately needed help with a pinball game: the collision detection was a big mess. This seems to happen a lot with Flash/Actionscript: you have very skilled application developers assuming that their skills will transfer easily to making games overlooking the fact that there are a few quasi-game-specific areas which you don’t generally learn while writing server/e-commerce/web apps. Unfortunately pinball is probably the worst possible choice of game to make if you’ve never dealt with physics/collision before. That was a hellish week, but also quite a fun challenge.

Anyway, our narrative has now made its way to the current year, good old 2007. In January we sat down and got back to work on Robotology, starting by figuring out exactly what the hell was going on with the simulator. Raigan was getting pretty stressed out by this point — in the spring of 2006 he game down with stress-induced shingles, and while the extended schedule helped to relieve the pressure that summer, the clock had started to tick yet again.

Thankfully, Mare came up with a fantastic plan: rather than scrambling about randomly, we would make a list of technologies which were known to solve the problems we were facing, and then systematically try to implement each one until we found something that worked. If nothing worked, we would revise our design to fit with whatever our technology could handle. The genius of this plan, amazingly, was that it was a plan: a nice, simple recipe for accomplishing a goal.

So, plan in hand, we made our list of the known technologies for simulating articulated bodies:

1. mass+spring systems:
   • a) Jakobsen’s Advanced Character Physics
   • b) Kacic’s A Practical Dynamics System
2. impulse-based rigid bodies:
   • a) Catto’s sequential-impulse method
   • b) Bender’s prediction-based method
3. esoteric/alternative particle-based methods:
   • a) Muller’s Meshless Deformations Based on Shape Matching
   • b) Muller’s Position Based Dynamics

Actually, this is a list of known technologies which not only do what we need, but which (more importantly) we could realistically implement! There are a wide variety of other methods which we rejected due to the fact that they were beyond our ability to comprehend well enough to use:

• The entire family of reduced-coordinate methods, which are pretty much custom-made for simulating articulated bodies as we needed, but which sadly require an understanding of “generalized coordinates”. These are things so terrifyingly difficult to understand/visualize/intuit that someone actually invented a completely different simulation methodology, just to avoid having to learn them! If you are interested, Kokkevis’ GDC2004 presentation is a good start.
• David Wu’s amazingly awesome implicit-Euler-based solver, whose presentations we read diligently every few months and yet still have only a 10-15% understanding of. This is really unfortunate since he actually presents a fully working method for doing exactly what we want to do: physically-driven skeletal animation. Sadly we just can’t quite wrap our heads around the advanced numerical/optimization math required.
• Weinstein/Guendelman-type iterative impulse-based methods; while these have definitely been used with success (jiglib), we felt that they didn’t really do anything that the previously-listed Catto/Bender methods didn’t, while being more involved/complex. So, why bother?

Hmm.. this post is definitely getting long. The results of our systematic experimentation will have to wait until next time.