flipCode - Tech File - Alex Champandard [an error occurred while processing this directive]
Alex Champandard
Click the name for some bio info

E-Mail: alex@base-sixteen.com

   03/05/2001, State Of The Art Character Animation

Firstly, I'd like to send out a big thanks to Phil for keeping the techfile updates going while I was busy with my project. Speaking of which, I'm now fully satisfied with the demo and need your feedback. Go to the bottom of the page! But first, as promised, a bit about the stuff that's so interesting that it got me side-tracked...

Parametric Skeletal Animation

If you don't know this already, PSA is the future of realtime animation. The concept is simple.
  • Start with a skinned mesh. It's probably easier to start by using one from a game. Half-life is a good start, as there are many models available.
  • Find a few basic animations: walk, run and stand for example. Make sure the cycles of the leg and arm movements match, i.e. the left foot starts behind at the first frame. The number of keyframes in the animation doesn't really matter, as you can do interpolation to fix that. Interpolation in realtime is probably not a good idea, but you can sample the animation and use fixed keyframes.
  • Export every bone from 3DS using a single quaternion to represent the orientation of the bone, and a vector as its origin. This can be done without a bone hierarchy: it would be quicker not to have to traverse the tree at runtime, and you only really need a hierarchy if you wish to do some Inverse Kinematics or Constrained Dynamics of any kind.
  • Each bone should have its own unique name, and keyframes should define the bone positions in terms of their names. If you use bone indices, it will get awkward when you change the bone structure of your character.
  • At runtime, you use channels to play back the animation at the right speed. This needs to be tweaked so that the walking cycles still match.
  • For a given number of channels, each bone can be arbitrarily blended in between them. This is done with spherical interpolation for quaternions, and a nice Catmull Rom spline for the origin vectors.
  • The blending factors can be controlled via a simple scripting language.
    child_blend( "bip01", walk 0.1, run 0.9 )
    All the children of the bone specified are then blended. This could also be done from the child to the parent, with some sort of falloff parameter:
    parent_blend( "bip01 l wrist", damage 0.8, walk 0.2, falloff 0.1 )
  • Animations can also be blended with procedural animations (physically based simulations, inverse kinematics)
  • Compute the matrices used for skinning given the final quaternions obtained, and render.
If you'd rather creating your own characters than using existing game models, walk through this tutorial, and this one.

Inverse Kinematics

Inverse Kinematics is a buzzword that many people don't understand. Until recently, I was one of them. The theory is quite simple, albeit the implementation can prove quite chalenging. Standard animation uses Forward Kinematics, whereby artist defined animations are used to determine the position of each bone. The movement of one bone affects all its children. At a given time, we know what relative rotation we must apply to each bone to get to the next position. This was most likely computed by our miracle exporter. We call this process Forward Kinematics since we move down the tree, not worrying about what has gone before, since we know it's right. With Inverse Kinematics, we are given a target point that a bone must reach. Now the problem is, we cannot immediately assume what the ideal orientation each bone of the chain must be in. For example, if you want to touch your nose with your finger, how do you place your upper arm?

There are several ways of doing this. One involves iteratively correcting the rotations down the chain until a point is reached. Look at Hugo Elias' page on Inverse Kinematics for more details. I'm currenly looking into simulating each joints as springs and applying a simple elastic force to the end bone. This should make the bone chain converge to the ideal position, where minimum strain is applied to each spring.

The potential for games is huge. You could fully define a walk cycle based on footsteps, whereby their position are determined by balance, injury, leg length, speed... You wouldn't get anymore 'moon walking' effects like for keyframed animations. Another example would be for characters to pick up and use objects placed in space. Picture a person juggling an arbitrary number of balls.

Soft Body Animation

I'm affraid I can't go into the details of this implementation for the moment, as I need your feedback. You can find a demo, and details of how you can help me right here.

It looks a bit like this:

You'll have to forgive the stereotypical nature of the demo, but my project supervisor said he wasn't convinced by my previous attempt. I had Halflife's Barney with a wobbly arm, and although I saw the potential straight away, I had to actually sit down and produce this demo just to convince him.

I guess I'm as not worried about my reputation as my house mates thought, there's not much of one to protect anyway :P

And a very big thanks to the live models...
Enjoy ;)

  • 01/05/2002 - A.I., Websites and Voxels
  • 03/05/2001 - State Of The Art Character Animation
  • 01/24/2001 - Alternate Programming Languages
  • 01/11/2001 - The Sound Of Silence
  • 09/20/2000 - Engine prototypes, yet more landscape LOD and hard body physics
  • 07/13/2000 - Good Practice (TM)
  • 06/13/2000 - Revision Week Indeed
  • 04/11/2000 - Escape From Inactivity ;)
  • 01/05/2000 - Generic Shaders
  • 12/03/1999 - Start Of Term: Lots Of Good Intensions :)
  • 10/06/1999 - Dynamic LOD, Landscape Generation and much more...
  • 09/22/1999 - Water Contest Entry: Rendering Raytraced Refraction with 3D Hardware
  • 09/16/1999 - More About Bezier Patches And Fractals
  • 08/11/1999 - The Right Landscape Engine For You!
  • 07/12/1999 - Leftovers From The Contest: Fixing TP7's Runtime Error 200 bug
  • 07/01/1999 - Introduction

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]