What's the best way to implement bones animation?

ehem... nobody? I'm just asking for a way to realise boned animation...

Well, it's a pretty broad question. What exactly are the goals of the system? What do you need to integrate it with? What does 'best' mean to you?

Best for me is: the most efficient.
OK; here's my situation: I have a 3D engine in OpenGL, and I need animated characters. So I thought of making animations with bones. My question is now: what are the different systems I can use and what are their qualities, useability....
See?

Still nobody...
Well yeah, I'll have to wait until the OpenGL Game Programming book arrives eh..

Quote:Original post by the_cyberlord
My question is now: what are the different systems I can use and what are their qualities, useability....

AFAIK, from least to most complex:

Rendering:
1. Block rendering (not sure how it's really called) - attach a model (block) to each bone, one model per bone, one bone per model; based on bone positions/orientations and hierarchy, find the transformation matrix for each bone; apply the matrix to the attached model. Very cheap, very simple, very crude.
2. Basic bone animation (again, not sure about the name) - same as 1, but on a per-vertex level (attach and transform vertices, not models). Cheap, simple, can look weird near the joints.
3. Skinning - same as 2 but each vertex can be attached to several bones, with different weights; apply all relevant bone matrices to each vertex, multiply by the weights, sum up the results, and divide by the sum of the weights. More complex, more costly, sometimes difficult to find good weights, but fixes the joints artifact.

Movement:
1. Key frame interpolation: interpolate bone positions and orientations (actually joint rotations and elongations/contractions, usually only rotations) from predefined key frames. Key frames may be set by an artist, recorded from motion capture equipment, etc. Good for general animation, most widely used.
2. Multiple animations: interpolate key frames like in 1, but do so separately for each body part and then combine. Allows to run two or more different animations at the same time.
3. Ragdoll physics: treat the model as an articulated object with only gravity/wind/shockwave/etc acting on it, and let your phisics engine (e.g. ODE) calculate the bone positions for you. Good for death animations, explosions, etc.
4. IK: define where some joint need to end up; set that as the target position for those joints; calculate the movements of the other joints taking joint constraints into account. Very complex, good for walking up stair, leaning on walls, refininig crude artist animations, etc.
5. AI control: train your AI to move the joints based on external input and bone-position feedback, then let the AI calculate the bone positions (goolge for "Karl Sims Creatures"). Very complex, requires AI training, limited applicability. Gives very natural-looking (organic) results if done well.
6. Hybrid systems: often difficult to combine approaches, but allows to do lots of advanced stuff.

Quote:Original post by the_cyberlord
Best for me is: the most efficient.

Most efficient for what? Size? Speed? AGP bus usage? Overdraw?

Aren't all these things super hard to do?
And forget about the speed, I would be soooo happy if I only could make such thing work!!

Quote:Original post by the_cyberlord
Aren't all these things super hard to do?
And forget about the speed, I would be soooo happy if I only could make such thing work!!

The basic things are relatively simple. Start small and work your way up. Google for some tutorials. If you don't understand them, come back here with more specific questions.
Goodluck.

The basic principle is that instead of specifying animations in terms of a vertex position for each frame (which Q2 used, IIRC), you group vertices together and apply the same transform to each of them. Then you arrange your vertex groups in a tree structure and have the transforms, stored in local space, collected as you move down through the tree.

The "best" way will always depend on your constraints - if you're speed limited, if you do or do not have vertex shaders available, if you need to conserve memory... they all implement the same basic principles, they just do it in different ways to fit the situation.