2. Related work

Before we start implementing a real-time solution for enhancing character movement, we take a look at related topics to fully understand the implementations coming next chapter.

2.1 Skeleton Animation Systems

Beside the mesh 3d-data representing the character, a skeletal animation system consists of a series of hierarchical transformations which represent bones. Like a real bone in a human body they influence the shape of the skin. Only the bone data needs to be stored for every frame of the animation. Usually, the bone data is represented by quaternions or a transformation matrix. This eliminates the need to store vertex positions for all the vertices for every frame of the animation, as in the vertex based animation. We can derive intermediate frames by using spherical interpolation.


Fig. 1: Schematic skeleton view

Advantages of skeletal animation are the smooth transitions while changing from one animation to the other. Additionally any number of animations can be added whereas the mesh remains constant and the same animation-cycles could be applied to different meshes while conserving a relative small memory footprint.


2.2 The need for skinning to generate a vertex-hull

Mesh (vertices) or skin is attached to the bones. Now when the bones move or rotate, the vertices attached to the bone also move or rotate according to their representative bones.One way of attaching vertices to bones is by using a single offset per vertex. So every bone tightly influences a group of faces from the character-mesh.

2.2.1 Single weight vertices & their disadvantages

The following images show the relationship of the skeleton / bone with its mesh. The semi-transparent object is the mesh. As you see, they are tightly coupled. When a bone moves, the vertices attached to it also move [Anderson2001].


Fig. 2: Schematic bone / skin view Fig. 3: Vertex / bone relation

Fig. 3 shows the same relationship as explained above. The only difference is that the mesh is shown in wire frame. The green line divides the vertices between the first and second bone. Vertices are represented by a small "+" sign. Vertices on the right are marked red indicating that they belong to the second bone, where as the vertices on the left are marked white indicating that they belong to the first bone. The following figure (4) highlights the main drawback of the skeletal animation system using a single weight per vertex. When rigid bodies move, the vertices attached to them also move rigidly.


Fig. 4: Single weighted vertex drawback

2.2.2 Multiple weighted vertices for smooth skinning


Introducing multiple weights per vertex improves the smoothness of the mesh-hull. This process is called vertex blending. This is achieved by allowing more than just one bone to influence each vertex, effectively mimicking the way that a bone in the real world would affect the skin of a living being. Each vertex is given information about which of the bones in the skeleton influence it and how great the influence of those bones is (skin weight). What we need is a skin that will blend smoothly between the rigid joints.


Fig. 5: multiple weights per vertex

Now every vertex is attached to multiple bones with different weights. This results in a smooth moving skin adapting itself to muscle-bulges and corners.

The generic blending formula:

vBlend = V1W1 + … + Vn-1Wn-1 + Vn (1.0-Wi)

Here vBlend is the output vertex, Vn the n-th vertex and Wn is the n-th vertex's weight.
For two, three and four weighted matrices, the above formula becomes:

vBlend = V1W1 + V2(1.0 - W1)
vBlend = V1W1 + V2W2 +V3(1.0 - (W1+W2))
vBlend = V1W1 + V2W2 +V3W3+V4(1.0 - (W1+W2+W3))

Typically, the vertex structure for a blending vertex looks like this:



2.3 File Format

As mentioned before, the more data is available, the fewer calculations are required. It is advisable to store only the data on disk that cannot be generated on the fly by the program. Let's take a quick look what data has to be stored in a 3D model file to support the animation of that model:

2.3.1 Skeleton
The data required to store a skeleton for an articulated object, apart from positional information for its joints itself, is the relationship between those joints. The easiest way to do this is by nesting the information for joints of a lower order in the hierarchy just below the joint which they are supposed to be connected to. For the joints themselves, all that needs to be known is the relative position of the joint which occupies the next higher order in the joint hierarchy of the skeleton. Bones (connections between the joints - vectors pointing from a joint to that joint's child joints) do not have to be explicitly saved in the file, as they are implicitly defined by the joints which they connect.


Figure 6: Hierarchic name convention for bones in X-files, exported from 3D Studio Max™

Each Frame can contain a FrameTransformMatrix, containing local transformations for that Frame. A Frame can also contain Mesh objects defining the vertices that form a 3D model, and child Frames.

2.3.2 Skin
The information which has to be stored for the skin of an articulated object, are the vertices which make up the skin. Each vertex structure has to contain data regarding the untransformed position of the vertex itself, the vertex normal, the UV texture coordinates of the vertex for texturing the model, a list of bones and skin weights, which define which of the joints of the skeleton are able to influence the vertex and by how much each of these joints influences the vertex.

2.3.3 Animation Cycles
Usually transformation information for all the joints of the articulated structure is stored in each key-frame of an animation. In the X-File format animation cycles are saved in the AnimationSet structure. Within an AnimationSet one can define a separate Animation for each part of the model which animates within the time frame of that particular animation cycle. Each Animation contains an AnimationKey structure which in turn contains a list of timed key transformations which will affect the part of the model referenced by the animation[Anderson2001].

[PREV] [UP] [NEXT]