Chapter 4. Architecture

This chapter illustrates the architecture of the Cal3D library. All the components and terminologies are explained in every detail.

4.1. Overview

The basic concept in the Cal3D library is to separate data that can be shared between several objects from data that is tied to one specific object instance. In the realm of skeletal character animation there is quite a lot of shared data: Take the animations and the meshes as examples.

The Cal3D library has a set of Core Classes (also referred to as 'core model') that represents one type of model and that stores all the shared data. Each set of Instance Classes (also referred to as 'model' or 'model instance') is constructed from the Core Classes and represents one specific instance of the model type.

Example 4-1. Warriors and Dragons

Say we have a little fantasy game with heroic warriors and deadly dragons. There will be 2 different core models, namely the one for the warriors and the other for the dragons. The core model of the warriors contains all the animations, materials and meshes of all possible warrior instances. The same holds for the dragon core model. Now, every time a warrior or dragon is born, a new model instance will be created based on its core model. The individual appearance is done by selecting specific meshes and materials from the core model. This allows us to have epic battles with numerous different warriors and dragons, even so we store most of the data only once.

4.1.1. Core Classes

As explained, each set of Core Classes contains all the data for one model type. This data can be divided into 4 parts:

  1. The hierarchical structure, see Skeletons and Bones for details.

  2. The motion data, see Animations, Tracks and Keyframes for details.

  3. The surface properties, see Materials for details.

  4. The body parts, see Meshes and Submeshes for details.

Figure 4-1. Core Classes

4.1.2. Instance Classes

Each set of Instance Classes contains the specific data for one instance of a model type. This data can be divided into 3 parts:

  1. The current state of the skeleton, see Skeletons and Bones for details.

  2. The active set of animations, see Animations, Tracks and Keyframes for details.

  3. The attached body parts, see Meshes and Submeshes for details.

There are 4 helper classes that simplify the model handling:

  1. The motion control, see The 'Mixer' for details.

  2. The skinning stage (Physique).

  3. The (experimental) cloth animation layer (Spring-System).

  4. The rendering interface, see The 'Renderer' for details.

Figure 4-2. Instance Classes

4.1.3. Miscellaneous Classes

The remaining classes can be divided into 4 groups:

  1. The math components, see Vectors and Quaternions for details.

  2. The error handling, see Error Handling for details.

  3. The encapsulated platform-dependent code.

  4. The helper classes for loading and saving data.

Figure 4-3. Miscellaneous Classes

4.1.4. Animation Pipeline

The process of calculating the final model from the core data and the current instance state must be seen as one single pipeline:

  1. The combination of all the active animations in the "Mixer" to get a current skeleton pose.

  2. The combination of all the active morph targets in the "Morpher" to get a current mesh (planned feature).

  3. The deformation of the current mesh based on the current skeleton pose in the "Physique".

  4. The simulation of the cloth parts of the model in the "Spring-System" (experimental feature).

  5. The querying of the final data from the "Renderer".

Figure 4-4. Animation Pipeline