Vizard 8 » Content Creation » 3D Models » Cal3D Workflow » Interface Overview
8.1
This section covers the general workflow for exporting avatars and also provides guidance on optional file structures and naming conventions.
Unlike OpenSceneGraph files, Cal3D avatars are always exported in multiple parts: A skeleton, various meshes, animations and materials. The first three (skeletons, meshes and animations) rely on object selection in the viewport. Materials are selected from a list within the exporter dialog based on what is found in the Compact Material Editor. The skeleton is exported first, then meshes and animations. The meshes and animations reference the skeleton file when exporting.
By splitting up the exports, geometry and animations can be shared between multiple avatars. This holds true as long as they are built on the same skeleton. Once every section is exported they are then assembled into a CFG file. A CFG file is a plain text file that acts as the character definition by specifying the name and path of each file you want included in your avatar. The CFG is the file that is added to Vizard to load the avatar.
There are a few things that need to be done before exporting:
While skeletons do not have to be from the same file and are often shared across multiple avatars, using a non-matching skeleton with a mesh or animation can have some very strange looking results. The exporter will try to prevent you from using a non-matching skeleton, but it isn’t 100% effective in detecting them. Using a good naming convention helps prevent mistakes.
See the Exporter in Depth section for more detail.
Does the export order matter? Yes and no. Most parts of an avatar can be exported individually and in no particular order, but there are a couple things that do need to be done before anything else.
First, you need a skeleton file that matches the one used by the character. This doesn’t necessarily have to be exported from the same file as long as it maintains the original base pose and bone names. In fact, it is common practice to build an initial character as a template then use the same skeleton for as many different finished characters as possible. Since meshes and animations in Cal3D are tied to a specific skeleton, you can minimize effort and overhead by breaking your characters into sets. Usually this means one skeleton for all Male characters and one for all Female characters, then additional ones for special cases such as children or animals.
Next, materials need to be tagged with a sequential ID number in square brackets before any meshes are exported, e.g. body[0], to allow the mesh to use the correct material. This acts as a material ID system that can stretch over multiple objects in the same Max file. This tagged ID is stored within the exported mesh file. Materials in Cal3D are modular, and are not tied to a specific ID. Instead their number is assigned based on the order they are listed in the CFG. In some cases it may be useful to add “placeholder” materials in the CFG to ensure a specific ID goes to the right material.
Cal3D does not require any particular naming convention for their files, and for individual avatars with few animations following a convention isn’t terribly necessary. It isn’t until you need to use avatars from more than one set that you start running into trouble. A good naming convention will make it clear which file belongs to which set, and will prevent similarly named files from being overwritten when directories are merged. Since most parts of a Cal3D avatar are dependent on being used with the correct skeleton, sets are usually named after the skeleton they use.
The recommended convention to follow is:
CFG: <group name>_<subgroup name>_<avatar_name>.CFG
Skeleton: <group name>_<subgroup name>.CSF
Mesh: <skeleton name>_<avatar name>_<mesh name>.CMF
Morph Target: <skeleton name>_<avatar name>_<mesh name>_<morph name>.CMF
Material: <skeleton name>_<avatar name>_<Mat ID Number>_<material name>.XRF
Animation: <groupname>_<animation name>.CAF
In practice, this looks like:
CFG: VCC2_maleHigh_CasualMale001_head.CFG
Skeleton: VCC2_maleHigh.CSF
Mesh: VCC2_maleHigh_CasualMale001_head.CMF
Morph Target: VCC2_maleHigh_CasualMale001_head_Talk.CMF
Material: VCC2_maleHigh_CasualMale001_mat0_head.XRF
Animation: VCC2_maleHigh_Walk.CAF
By default, Cal3D looks for files within the same directory as the CFG file. The most basic structure you can have is no structure at all. This is fine for simple cases and testing, but a lack of organization can make it difficult to keep track of assets. Since Cal3D is not able to search for files in subdirectories on its own, any subfolders used will need to be specified in the CFG, with the exception of Maps. The subdirectory for maps is specified within the material files, so it is usually better to export materials as XRF so they can be modified in a text editor if necessary.
A step up from the basic structure is to organize assets into a subfolder based on the character’s name. E.g. an avatar called Male03.cfg could have its assets in a subdirectory called Male03_Assets. If all assets for the character are completely unique then this can work out fine and make transferring a single avatar with all its individual assets a simple process. However, if the avatar shares assets with numerous other avatars in a set, this structure can lead to large amounts of duplicate files. When Assets are organized for complex avatars, the folder structure generally looks something like this:
model.cfg
Anims/
/AnimSet_Idle/
/AnimSet_Walking/
AnimSet_Running/
Maps/
Mats/
Meshes/
Skels/
In this example, groups of similar animations are being kept in subdirectories of the main animations folder to further aid in organization of both the folder structure and the CFG code. While it can be a little more complicated to isolate the assets used by a single avatar, it keeps things nicely organized without causing any duplicate files.
Exporting avatars in multiple parts can be good or bad depending on the circumstances. On the downside, it can make exporting avatars very time consuming, especially when exporting large number of animations manually. On the upside, the modular nature allows any exported parts to be shared among any other avatar that uses the same skeleton. This allows for modular approaches to character creation (e.g. changeable clothing) and a much lower overhead than if each avatar had to store it’s own copies of all the animations. A wide variety of avatars can be generated from a relatively small number of parts.
While animations can be shared with other avatars from the same set, Cal3D does not support retargeting. Animations from one unique skeleton cannot be used on another without re-exporting. Attempting to use an animation on the wrong skeleton often has strange and monstrous looking results.
Each kind of Cal3D file can be stored either as a binary file or as a plain text XML file. For large files like animations and meshes, binary is the most useful because binary loads faster. The main use of the XML version, other than for diagnostic reasons, is in making Material files. It is generally faster to edit an XRF in a text editor to fix a material problem (e.g. wrong texture path) than it is to go through the trouble of fixing it in Max and re-exporting the material.
Please note that while Max also has its own animation format with the extension XAF, this is separate from the one listed here and is not compatible with Cal3D.