I've created this thread to discuss the pros and cons of various implementations of 3D animated models, the kind used for players and enemies in 3D games. There is much confusion in this arena.

I have found that they all fall into two major categories. Both versions use "keyframe" information, but they apply it quite differently.
A) pure vertex animation
B) skeletal (bone) animation

An example of (A) is the MD3 format created by ID Games.
These files contain N frames worth of VERTICES for the model, ie the entire mesh worth of vertices appears N times. You might think of this as N poses of the same model.
They have rather large datafiles, but very fast to animate at runtime, because you only have to lerp the vertex data between any two frames.
Animations in MD3 files are sets of keyframe information which describe a series of frames to "play". An MD3 model is constructed from several static submeshes, where each submesh describes the vertices of a Bone - so they always have problems at the joints when animated. That is to say, the vertices of an MD3 model are "glued" to a single bone. You might imagine a toy soldier with moving parts - pretty bad, huh?

An example of (B) is the MD4 format (also by IDG).
These files contain ONE copy of the vertex data, so they're a lot smaller.
The vertices are associated with one OR MORE bones by Weight, which means that there are no harsh joints in such a model. They are more expensive to animate at runtime. The keyframes contain information for animating the Bones rather than simply identifying which "poses" to lerp.
Each bone is represented by its position and orientation (with respect to its Parent, not the world). Surfaces have a list of Bones which affect them, simply a list of Bone indices per surface.
We don't animate the vertices directly using (B), we animate the Bones.
Surfaces are deformed by Bones, and therefore vertices are as well.
Animations in MD4 files describe transformation matrices to be applied to bones.

Who else is interested in this stuff?
Posted on 2004-12-02 01:16:23 by Homer
I guess you also have to consider what can be done with hardware vertex shading, and what requires code on the CPU. These days it's a bit silly animating on the CPU if the GPU can do the job... but what do I know ;)
Posted on 2004-12-02 01:36:39 by f0dder
well im surely interrested in this topic, but thats because of my great curiousity and my 'need' to find out how things i see work :)

well i never really did understand bone transformation but after redaing this it got me a much clearer vieuw.

btw, it is possible to get a good animation with only vertex transformations but its a bit harder to get a realistic look, true

im not really sure which i would prefer above the other one, vertex moving is fast but requires more diskspace
bone moving gives a better look, costs less diskspace but needs more calculating.
i would say go for Bone moving, i mean cpu's these days can keep up with it and you get a more realistic look
but i also had the idea of combining the 2, you can use bones for animating the 3D model but when compiling it (you need to compile it this way) you use the bone animations to covert the animations to vertex movements and save that, so you will have the speed advantage on a realistic looking model, does sound nice to me :)
but then there is still the 'size of model file' isue, this gives a limitation in the number of vertexes and duration (number of frames) of an animation and offcourse the number of animations considering the harddisk space...


edit: GPU? hehe, ill look at that after school ;)
Posted on 2004-12-02 01:38:42 by Scorpie
I too prefer the second method, regardless of the cpu overhead, it means you can have more models in memory, meaning more models on screen.

Yes, to a certain extent, the gpu can be used to accelerate models stored on the hardware, at the cost of having less gpu memory available for texturing... and since most people don't have these kinds of cards yet, but do have decent cpu speed, I think the gpu memory would be better used to load more textures... thoughts?
Posted on 2004-12-02 02:37:00 by Homer
Here's my 2 cents.

Ignoring the cpu overhead for the moment, skeletal animation offers greater flexibility and control since the model and skeleton are seperate entities.
This gives you the ability to use a single set of animations for all your humans for example, regardless of which model is used, although you should use a seperate skeleton for the ladies to capture that cute wiggle they have ;)
Skeletal animation also gives you the ability to add new animations to existing models simply by supplying a new skeleton.
If you don't mind burning the cpu power you can combine skeletal animation with IK and animate the skeleton using guide wires instead of keyframes. I don't know how well it would work, but the possibility is there.
And lets not forget to mention the obvious advantage skeletal animation has with regards to ragdoll physics.

Yes skeletal animation requires more cpu overhead, but as cpus become more powerful and vertex shader capable cards become the mainstream, this issue will become mute.
Posted on 2004-12-02 05:36:45 by Maelstrom
Doesn't facial animation requires too many bones for realistic movement? Facial animation is very important for any game with people! I'm all for bones, but think it is not enough.
Posted on 2004-12-02 09:46:09 by bitRAKE
For the problem with facial animation - yes, I choose to handle the vertices, for all else - the bones. But dealing with the bones, I wouldn't want my games to look like MortalKombat 4 eeew. There the meshes never shared vertices, and the players looked as if made out of limbs of dead animals. It's best to have meshes sharing vertices, as in CS/halflife, move the bones in a hybrid of keyframing and dynamically generated transformations (interpolation), and move the face vertices with similar hybrid keyframing.
Thus your models will never seem to change states immediately, your animation data will be less - and much easier to modify/create/clone

Interpolating between two keyframes is what I always use when animating 3D characters - I need to add another keyframe to fix-up the animation only when animating the feet- since they can sometimes dig too deep in the floor :) But for all other situations so far, interpolating is the best-looking and fastest way to do my job :)
Posted on 2004-12-02 14:55:30 by Ultrano
As far as IK is concerned:
Most IK implementations I have looked at used the same methadology of interpolating between the model's current pose and the "final" pose. They worked in a backwards fashion, calculating all the angles and positions for the bones in the "final" pose, then interpolating the bones from their current values to their final values.
I've not heard of "wireguide" but I assume you refer to constraining one or more bones to one or more guide curves?
Regardless, as you can see, it's not so hard to apply IK if you can manage to find the final pose... in order to do that, you employ an "IK Solver" which is the algo I described plus position and rotation constraints for the bones (so that elbows can't bend backwards etc when under IK)
Posted on 2004-12-02 22:30:48 by Homer
I've not heard of "wireguide" but I assume you refer to constraining one or more bones to one or more guide curves?

Yeah, just an idea that was bouncing around my skull. Its probably not particularly useful for defining complex animations, but could be used to define simplier animations that could be supplied externally by mod makers. For example, a 2d glyph defined using curves could be used to animate the casters hands when casting spells.

bitRAKE: With regards to facial animation, wouldn't a basic skeleton be required to handle the jaw and possibly the eyes?
I was very impressed with the facial animation of Half-life 2.
Posted on 2004-12-02 23:48:10 by Maelstrom
Maelstrom, bones have been used for these things in the past, but 'required' implies a rigid perspective which I don't maintain. Half-life 2 has very few characters on the screen - bones work fine.
Posted on 2004-12-03 01:20:50 by bitRAKE
bitRAKE: Sorry, I should have worded the question better. I didn't mean to imply that you *must* use skeletal animation for the face, but was asking if a minimal skeleton could be used to represent the largest elements of the face with finer facial expressions to be handled by vertex shaders or the like. Half-life 2 apparently based their system on the behaviour of the facial muscle groups so I'm assuming that most of the facial expressions are handled by vertex shaders.

EvilHomer2k: Something I always wanted to do with skeletal animation when I got around to it was to have my characters actually *walk* up stairs instead of simply gliding up, actually put their foot on each step. Would IK be the only way to achieve more realistic interaction with the *ground* like this?
Posted on 2004-12-03 13:06:10 by Maelstrom
Characters - Advanced facial animation system delivers the most sophisticated in-game characters ever seen. With 40 distinct facial "muscles," human characters convey the full array of human emotion, and respond to the player with fluidity and intelligence.
It is difficult to tell exactly what has been used for facial animation. Could it be 40 bones?
Posted on 2004-12-03 16:45:30 by bitRAKE
It is difficult to tell exactly what has been used for facial animation. Could it be 40 bones?

Anything is possible, but wouldn't springs represent muscles better?
You would probably still need some type of facial skeleton to attach the springs to, but it could allow for some interesting possibilities. Expressions could then be generated by applying loadings to the appropriate springs, but I could just be talking a lot of crap.

I'll have to pull my finger out and code something to play with.
Posted on 2004-12-03 19:17:25 by Maelstrom
There are three major kinds of facial animation : they are called "phonetic interpolation" , "lattice deformation", and a combination "hybrid" of the aforementioned, afaik.

I think we can guess from their names what is entailed for each :)
Posted on 2004-12-05 03:21:25 by Homer
afaik bone animation is used VERY LITTLE for facial animation - it's just not refined enough for this sort of thing, but is often used in combination with lattice deformation.

re contact with the ground (and other stuff) - YES AND NO.
IK is very expensive, and we should avoid it wherever possible.
Here's some thoughts I had on this dilemma:
Collision detection is applied to each foot (sphere detection), this is used to determine the endpoint of a footfall. Now we have a problem to solve (we need a "Solver") - is the foot at the end of its animation sequence? If we are on flat ground, then yes it is, we dont need to worry... but if the ground is elevating, our foot will have collided with the ground "early" - the animationsequence is not complete - and if we are on declining ground, the opposite problem - the foot will be BEYOND the range of motion provided by the animationsequence... Can you think of a way to reconcile the animationsequence and the foot? One way I thought of is to animate the legs separately, doing away with the conventional notion of a walk animation, such that our animationsequence is comprised of two overlapping animations, one for each leg... now reconciling the animation can be easier, especially if we deliberately make each walking step for each leg larger than it needs to be to handle the case of downhill marching...
Posted on 2004-12-07 09:37:11 by Homer
What if we could still use the base animation, but dynamically tweek it based on the slope of the terrain?
When walking up hill the front knee would need to be raised to counter the increase in height, but when walking down hill the back leg would need to bend, lowering the body, to allow the front foot to reach the ground.
If we could quickly determine the height difference between the current and end position of the feet, this could be feed to the animation manager which could tweek the animation.
This could allow for a dynamic system which would automatically adjust to the slope of the terrain.

Posted on 2004-12-07 22:34:40 by Maelstrom
This is possible, but only works on a per-surface basis... consider an undulating terrain and you will see what I mean.. now confront your model with a staircase (your original example) and we have no "slope" anymore, just a series of flat surfaces at varying heights ... collision-based animation tweaking sounds like a better universal solution, would you agree? I'm sure I could devise some diagrams to pictorially describe what I posted recently... any other ideas?
Posted on 2004-12-08 02:59:12 by Homer
A collision-based animation tweek sounds interesting and deserves further discussion.
We could probably make use of the collision already being done for the feet, since I want to be able to kick things as I walk.

but only works on a per-surface basis... consider an undulating terrain and you will see what I mean

To be able to step on/over things like logs, rocks, dead goblins, etc, would probably require us to determine the position in the animation that corresponds to the highest point we need to step on/over, then adjust the animation to raise our leg up high enough to clear that point, then onto the final position?

Pictures are always good, easier to understand sometimes, post away.
Posted on 2004-12-08 07:21:58 by Maelstrom
It sounds like you have a pretty good idea what I meant...
implementing a new idea is always fun and a challenge :)
Posted on 2004-12-08 08:09:10 by Homer
That's why I love programming, there's always something new to try.

I am surprised at the low level of interest, everyone busy with life or just not interested?
Posted on 2004-12-08 21:30:51 by Maelstrom