basically the principles are the same but games are more restricted in what you can use to create the deformations you require. basically we use joints for everything as the engine can build joints cheaply (sometimes we use blendshapes (morph targets) but in some of our engines were limited n the number we can use, and how many can be used simultaneously, so we avoid these if we can). but unless the programmers have coded in support an particular deformer, or setup an in game real time deformer, you cant use things like lattices, clusters, wraps, dynamics.... ect
so for instance if you need a dynamically jiggling thing youll need to constrain some joints to it to deform the mesh (pretty simple), where as in feature rigs your free to deform the mesh directly as the output is just the rendered mesh. also if your setting up this dynamic object to be animated in your app (Maya , max, xsi...whatever) you'll need to give the animator the abililty to bake the animation out. so it can be set to a exact position so it will match if blended with another animation
also one of the main things we do is keep the joint hierarchy separate and clean, as in a joint can only be parented to another joint (not a group under another joint with an offset position)
also one other thing (that causes some debate in my place of work :) ) is that the fact that, in games, you are limited to joints and usually by the joint count. so you will have to position your joints slightly differently. by this i mean if you were building a feature rig with a full muscle system you can be as anatomically correct with your joints as you want as you know the mass and volume should be simulated pretty realistically, but if you need to use one joint to control the whole area of, lets say, the shoulder/clavicle then if you place that anatomically in the right place you'll get some nasty rotations on the back of the skinned clavicle as you rotate it forward as it will be too far forward. so you'll need to play about and test :).
well that's how Ive found it although there are some people who stick to anatomy, but when it boils down to it all if it deforms better that's the right position.
oh and also we've had to, in the past, rig joints with he scales inline with he world as some engines cant handle non uniform scaling. so for that we had to use the rotate axis to orient joints as that leaves the scale (think this is calculated after the scales in the matrix multiplication). which can seriously hamper any stretchy joints or other cool rigging techniques. we then have to 'fake' it with translations of another skinned joint.
(andylt1)
The key difference is this:
A game rig has to last the course of the game. A film rig only needs to last the length of the shot. I.e you can make rigs in film that only need to work in one angle/shot but for games generally the rig has to work in and from every direction/shot.
Other differences, muscles, deformation are getting smaller and smaller every day - the Crysis rigs are getting pretty close to film rigs in terms of technology.
(eek)
There are two Key Differences.
Game Rigs need to have the correct Transform information in the animation.
Parent Constraints directly to the In Game Skeleton will not give you the right transforms.
Take for example: 1 bone skinning 1 cube. The Bone is parent constrained to a Nurbs Circle. When you animate it, none of the transforms the circle goes through will translate to the bone. The bone will only have the animation data relative to the parent.
Now, if you take the same setup, but instead of a Parent constrain, you use Point and Orient Constrains. Then everything will come through. Any animation applied to the Nurbs Circle will applied to the bone.
Second Difference.
Vertex Animation, For the most part, Blendshapes are as far as Game Engines go. Everything has to consist of Bones and/or Blendshapes. There are of course ways around it.
one Minor thing that you won't hear much about is Vertex Influences. Games have to run smoothly, so often the Vertex Influence is limited to 3 or 4 bones.
All in all, You can't cheat as much with a Game Rig. The Film Industry has it easy compared to the technical headaches of game rigging. But I do suppose they demand higher quality as a result.
(Brighton)
Also, try to keep joint chains short for game rigging..
The best advice i can give is to keep your animation rig separate from the bound skeletal hierarchy.
If you add nulls, locators and other objects into skeletal hierarchy it will cause crashes and major problems in the engine.
The bones should be a single hierarchy, in film you can do some really cool broken hierarchy rigs, but in a real time engine, you will just get a broken character ;)
One last thing, depending on how many characters you need to be rendered at one time will determine how many bones you can use. Anything over 70 or 75 (I forget which it is) in some engines will have to render a second pass (killing optimization)
(JamSession)
Nowadays there's not much difference aside from the deformers that can be used (in film you can get some pretty nifty results with stuff like offset curve deformation that a runtime doesn't support/understand). The rig in games is pretty much throw away material and the export skeleton/bound skeleton is the key piece so the rig can be as crazy as the animators need so long as it's just simple bone data going to the engine.
As pointed out above you can't use broken hierarchies for game skeletons as it all needs to be a consistent hierarchy from top to bottom to get exported properly. I've seen people try it on rigs for games constraining to an export skeleton but I've never seen solid results from it.
(BoostAbuse)
Hey Shawn, I'm confused by your answer. Did you mean constraining the export skeleton to an anim rig? I've worked at 2 different studios that used this process with great success. We created a bind rig which is just the export skeleton and the skin and the anim rig drives the bind skeleton via constraints. This process is quite helpful in large productions where depending on the complexity of the character and rig, one person can be setting up the anim rig while another person working on the bind rig and have some sort of "publish" tool that connects the two rigs together . We use this same paradigm here more or less.
-Sean
(NolanSW)
Hey Sean, long time no see :) The constraining part is fine as I've always worked that way as well but we tried a couple times to use broken hierarchies for the rigs and then constrain the export skeleton to the "pieces" of the broken hierarchy but never got solid results so we just rebuilt the rig with a hierarchical structure rather than use point/orient constraints to attach hips, arms, heads etc to the rig skeleton.
(BoostAbuse)
Global Scaling on a Broken Hierarchy
Turn off 'Segment Scale Compensate' on the joints..
non-comprehensive list
CryEngine
Crysis
Exporting animated models from Maya to Crysis (SeithCG)
Unity
http://adammechtley.com/2011/04/an-automated-pipeline-for-generating-run-time-rigs/
(also talks about his shoulder plugin)
Blendshapes available as of 4.3
bones should be set up to work w MecAnim system.
Lin Chou Cheng's Game Animation with MecAnim
MecAnim en Espanol
Toggle Keys in Unity?
Unreal
Fast and Efficient Facial Rigging (Jeremy Ernst, GDC 2011)
Some excerpts:
To deal with outsourcers: packaged all the autorig scripts into an executable so they wouldn't get lost/cause trouble. Used Smart Install (www.sminstall.com)
In Gears 3, we have a game mesh
and a cine mesh. They are the same mesh, but are just weighted differently to allow for applying the same animation on either. This way, we
can still be smart about how many weighted bones we have in-game, but when we need the extra deformation for close-up cinematics, we can
load in those weights.
recommend reading:
Metal Gear Solid 4 article (version with images here)
CG Society - Curious Case of Benjamin Button
Facial Rig is made up of four main layers:
1. low-res poly cage to make morph targets with - all animatable attributes are derived from morph targets made w/cage
2. locators pinned to the surface of cage, that move w/the morph targets
3. 'offset rig' - controls that move with these locators and then allow offset from the pose
4. joints that actual model is weighted to--these are constrained to offset controls