wardred said:
Eniko,
I could be wrong but I always thought the animation was kinda static. Like 2D, but with more "frames" for you animations - usually. (I remember Quake 1/2 animations seemed very much legs together, legs apart...legs together, legs apart... Many 2D games seemed to have more frames of animation.) So you'd have a walk/run/jump cycle pre-calculated, and all you'd do is tell the character which direction it was pointing in, what "frame" it was on, and have a point reference for its place in 3D space. The "animation" would be pre-done in your your rendering package of choice. It gets a little tricker with hills or steps, but mainly that would be calculating the height of the character, I thought. Is it worse than that in most games?
Actually, since 3D graphics are vector-based, they correspond more closely to Flash animation than traditional 2D sprite animations.
Here's sort of how it would go, from simple-but-inefficient to modern techniques:
1. Storing a whole vertex array for each frame - I don't think this was ever actually used
2. Storing a whole vertex array for each keyframe, then interpolating between keyframes. IIRC the early Quake and Quake II engines used this.
3. Storing a skeleton and then keyframing the skeleton. Works pretty well, still used in many cases for general character animation. However, facial animation, at least in Source Engine I believe, uses "morph targets", which are sort of like keyframes that can pull the face into multiple different directions at once to form complex animations. Usually you combine a whole bunch like "raise eyebrow", "smirk", "smile" or something.
4. Inverse kinematics - This is hard for me to explain, but it's a superset of "foot planting" animation. The graphics engine uses environmental data and loads of trigonometry to position the ends of limbs in global space (such as feet on the ground, or hands on a lever or something), then move back up the skeletal hierarchy so the knees / elbows are bent and angles just right. Usually, there is a predefined skeletal animation as the base, and then the engine adjusts everything slightly after running the forward kinematic animation. Jurassic Park:Trespasser tried to use this for every animation, to horrid effect. You can see velociraptors plant their feet as they stumble sideways into the player character, while their bodies bounce up and down. Not to implemented in a hurry at all.
5. Other things. Skeletons have gotten more complicated with modern games. Apparently they have to model muscle bulges and stuff so the ACH DEE GRAFIX look just right, like in CINEMATICS. SARCASM CAPS
s
1 is easy to do, but eats hard disk and memory. 2 is pretty simple, but requires a lot of keyframes, since it will interpolate everything linearly, which causes rotating objects to shrink and expand in odd ways. 3 is pretty difficult since there's trigonometry involved and I could never get Blender to export anything right. 4 is probably simple once you get 3 working, it's mostly within the engine as opposed to working with an animation editor. 5 is overkill for homemade games.
