Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
Can anyone explain the general architecture typically used for 3D character animation?
Are movements like walking and falling scripted against the skelton, and simply executed on input? If so, is the scripting typically actual script or hard code?
What are common pitfalls or flaws in character animation engines?
Yep, an animator creates each animation (falling, walking, idle) in a specialized program, as well as intermediary states between those (idle to combat ready, starting to walk, stopping). A finite state machine is used to describe what animation states can lead to which seamlessly - this can be implemented by the game engine or not.
Modern engines can interpolate between two animations, so there's no need for the intermediary animations and pretty much any animation can lead to any other.
Common problems with this method: Animations need to be tailored to each model (or fatter models will intersect themselves when crossing their arms) and don´t adapt themselves to surrounding terrain (walking up a ramp uses the same animation as walking down one)
Normally when I approach character design I work on the character model first, once I have a good starting point I start to add "bones" and "weighting" for the "skin" of the model.
You mentioned a skeleton, and in this regards I believe that these are the same. The bones act as the handles that you grab to control shaping the model. I start from the head to the center of the neck, two out to the shoulders and one down to the torso.
From the shoulders I go out to the elbow and then to the wrist/hand (the hands can be as simple as one bone or as complicated as three in the center of the hand and three for each finger, two for the thumb - but I rarely go that deep).
From the torso, I do two for the ridged hip and then down to the knee, to the ankle and one for the foot (with shoe or simple, as the hands this can become as complicated as you'd like).
The less bones you have to place in your character the less you have to deal with in terms of data mechanics/control points. If you have a lot of bones then it will take more time to map the weighting for the surface material — add as you need to, but keep it simple.
Depending on what you're doing with the model depends on the next steps. If you're rendering out the animation sequences you can build out a series of animation types. One file per animation from a normalized starting point. Then build out, walking, running, jumping and other animation sequences. Render out and then create keyframes for moving from one point to another.
If you're actually building a model to us in a 3D application then the model must be adjusted within the code. Create a series of animation sequences, much like you would with keyframing, but shorter/in-between steps, and then "tween" the sequences. This will allow you to start a walking sequence and add a look left to the "animation stack" at the same time without having to write a "walk and look left" sequence.
Creating animation mix-ins is handled in code and again, this is another good reason to have as little bones as possible in your model.
You can also create/use motion capture models and attach the model to the keyframe sequence of the bones of your model. This allows you to use the same "action" on various models (and associated bone rigging).
And yes, the standard way (in the past) was to keyframe each animation block (and then render it out) and then change from one state to the next, much like Srekel's suggestion. This goes back to the days of sprite animation where keyframes were used in story boards and the animators just had to fill in the "tweens" or frames in between the two keyframes. As mentioned this is older and not as flexible as current systems allow.
Think of a 3D model like an avatar in World of Warcraft or the like. In the selection screen the model stands there, and at times shifts weight from one foot to the other, or will blink or look in a direction. These are all small fragments of motion (animation blocks) that are just added in realtime so that the character has a more dynamic appearance and not static like those old Mortal Combat games. (^_^)
I'll see if I can find a couple of links for you and try to remember to post them here for you.
Also, I'm not an expert in this field but I do like to play in it. So, take my comments with a grain, dash, spoon or pillar of salt and good luck in your animating endevors!
Cheers, Kevin
There's quite a bit of information about this in Game Engine Architecture ( http://www.gameenginebook.com/ ).
In general you often have a state machine that specifies which animations can transition into which, and how that transition is done. For special cases like the main character, you also often need to hook the transitions into custom hard coded functions for doing various things - there's generally more logic to the main character player mechanics than to NPCs.
