I finally put up a write-up for my GDC talk, An Automated Pipeline for Generating Run-Time Rigs, for anybody who’s interested. Thanks to everyone who attended, and to everyone who takes the time to read!
http://adammechtley.com/2011/04/an-automated-pipeline-for-generating-run-time-rigs/
woot. thanks!
Hey Adam, do you have metrics on cost of runtime rigs vs. anim data? I have had some interesting debates with programing about this. comes down to CPU vs. RAM often but it is never as clear cut as all that.
Thanks,
Brad
Hey Brad,
I’m going to hazard an answer to your question by not actually answering your question (in the sense that I don’t know how helpful any particular numbers from me would be, since things are often so specific to project and platform requirements—I’ve never been in a situation where the cost for the rigs was especially high, but I’ve also never made games with dozens+ of simultaneous characters).
Some caveats: working on lots of small games, I’m generally in a position to take a fairly “whole-project” view. That being said, I tend to adopt the perspective that there are just a bunch of different places I can hit a ceiling (e.g., CPU/VFP [iPhone], RAM, build size, production capacity [cost, time, personnel, whatever], etc.). The natural consequence here is that for most of my work, the production capacity ceiling tends to be the first one I hit, with build size probably second most common. (These are both places where run-time rigs have saved me in one way or other, by the way!)
Those caveats out of the way, I can give a quick example with Touch KO 2.0 (which I recently killed). Retargeting for height differences and stance differences can be pretty trivially resolved with some 3-key additive animations for each attack (for each retarget required)—at least it’s close enough for government work, as the saying goes. However, moving the whole moveset to higher-fidelity mocap, increasing the number of unique sounds, etc. sometimes pushes too far for comfort against the memory ceiling on a first-gen device.
So, where am I freed up? Sounds are already as low of sample rate as they can be (without just being random barf garbage), and it’s faster to play back an uncompressed sound, so I can’t really budge on them without creating lots of boring silence. In this case, knowing which things are handled on different processors, and where I’m sitting on them, the cheap solution was to eliminate all the animations for the opposite stance (southpaw) and just apply a negative x-scale transformation to a character (by using a separate mesh with reflected vertices/normals, reverse winding order, swapped left/right bindposes, etc.). I know this probably doesn’t really sound like a “run-time rig,” but remember I’m basically just talking about transforming animation data when I use the phrase.
Anyhow, I hope that’s more helpful than just random rambling. Unfortunately, I don’t know anyone who’s done this on a large enough scale to offer you a more pointed answer (maybe they’re here on the forums).
That does help, thanks Adam.
Good trick with the mirror animation.
Run time rigs may sound out there for some people but when you come down to it, HIK layer and rig in MotionBuilder is exactly that. It is a run time rigging system and there are lots of games that are using those rigs with large animation data sets… the more runtime rig stuff used the less animation data you have taking up space with less FK compression artifacts that normally show up on the legs.
Great response though and helps give me better insight when reading your talk.
[QUOTE=bclark;9966]Run time rigs may sound out there for some people but when you come down to it, HIK layer and rig in MotionBuilder is exactly that. It is a run time rigging system and there are lots of games that are using those rigs with large animation data sets… the more runtime rig stuff used the less animation data you have taking up space with less FK compression artifacts that normally show up on the legs.[/QUOTE]
I should note I never want to come right out and say it, since I haven’t had enough experience with e.g. HIK run-time to confidently (loudly) comment on it, but my gut tells me if a game can afford something like full-body IK, a lot of the other applications I see for run-time rigs are computational dwarfs in comparison 
Excellent read. Thanks for posting.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.