|
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 ;)
Alex
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.
|