Coding an animation lib

quote:

---

Original post by INVERSED
I was wondering if anyone could point me to some docs on how to code an animation engine. I'm thinking I want a bone based skeletal animation system. I have the code for Cal3D, and am going through that, but I always have trouble using other people's code, and rather try to work through it myself before I resort to hacking an open source lib. Any links would be much appreciated.

---

You might want to checkout the new animation stuff that came with DirectX 9, the new animation controller has a lot of useful things built in.

Edit: I'm using it in my engine and I'm quite pleased with the performance so far.

[edited by - SiliconMunky on November 26, 2003 2:43:11 PM]

Unfortuneately I need everything coded by hand in a platform independent type way.

Hi,

if you want to code your own animation engine, I''ll suggest that you take a deep look into your system. If you already have build an working engine, you should at least have some kind of object structure (containing position, orientation and scaling), a decent math lib and a renderer

A bone based animation engine needs a bone based object hierarchy. So, in fact, you have two options :

a) You include the animation functionality into your object structure.

b) You create a seperate animation engine that mirrors the object structure you use in you game engine/renderer.

For both ways there are pros and cons. Here are the ones that come to mind :

A)
pros : - less code to write (the structure is already there)
- easier to handle
- can be highly optimized for you object structure.

cons : - less flexible
- you''ll have to load the animation set for every hierarchy
- uses more memory (due to the point above)

B)
pros : - very flexible
- one animation set can be put onto multiple hierarchies
- good seperation between animation and render engine
- uses less memory (if applied to more that 1 object).
cons : - a little bit more code (since you''ll have to mirror the object structure)
- a little bit more complicated
- more math to do.

I''m quite a fan of B since it provides a very flexible way to handle stuff.

Basically you have these classes :

IBone : Interface to a bone (ie. ObjectBone, HelperBone, SkinBone)

IController : Interface to a controller (ie. PositionController, RotationController, ScaleController; but also : TextureController, ColorController, ...)

Eventually you have a IAnimationSystem which handles the updates of the animations, the loading of the data sets, the application onto a structure etc.

The IBone derived classes will mirror your object structure in your engine. Normally, as I said above, this includes a position, an orientation, etc. You can add and remove controllers to this class and invoke an update. Once the update is done, the new values (position, orientation, etc.) are then applied to the object the bone is attached to.

The IController derived classes manipulate the values stored in the bone they are added to. They are called by the update function of the IBone and, dependently on the time frame and their time, alter the content of the position, the scaling or the orientation.

Basically that''s it.

There are some "advanced" options such as "mapping" an animation set onto an object hierarchy that is not the origin of the animation (ie. you have an animation for Man02 and you want to apply it to the object hierarchy of Man01. If the two hierarchies aren''t 100% the same, you''re in trouble if you don''t apply some kind of mapping).

Kind regards,
Metron