Vizard 8 » Content Creation » 3D Models » Cal3D Workflow » Exporter in Depth
8.1
This section covers the exporter interface and export process in detail. It provides step by step instructions for exporting and a brief look at how each item is added to the model’s CFG file.
Exports in Cal3D always start with a skeleton. Exports are based on the current selection and use Export instead of Export Selected. Meshes and animations are dependent on being used with their own specific skeleton, so avatars are usually grouped into sets based on the skeleton they share. For this reason, the name of the skeleton file is often used as the name of the avatar set.
To export your skeleton:
In a CFG, the line that specifies the skeleton should come before mesh and animation assignment. In older versions of Cal3D it was necessary to use a Scale command to convert the avatar to meters, but this is now performed automatically upon export.
If some bones are missing verify that you have selected the root and that all bones you want included are linked to it. If you are using floating bones, select the root of each separate hierarchy before exporting. If you see any part of your character’s mesh listed among the bones, verify that it isn’t selected or linked to any bones - eye meshes should always be controlled through skinning.
Meshes exported for Cal3D are fairly straightforward to export. They can be one individual mesh, or in multiple parts. You can also export multiple meshes together as a single CMF without needing to merge, or you can export them individually if you’ll be swapping them with other parts later on.
Since meshes are dependent on being loaded onto the correct skeleton, the name of the exported CMF file is usually the name of the skeleton + the name of the avatar + the name of the specific mesh. When building a set of avatars to use the same skeleton, build one avatar first then save its skeleton out to a .FIG file containing the name of the set, e.g. male.FIG. When building the other avatars, load up the .FIG file onto a new biped and build the new mesh around it. It is also common practice to build a generic avatar as a template for the others.
Before exporting your mesh(es), you’ll need:
To export your mesh(es):
Afterward, select each additional mesh and follow the same process. If you get an error saying that skeleton assignment failed, you are probably loading the wrong skeleton. In most cases not getting the error means you have selected the right skeleton, but in some cases an incompatible skeleton won’t be caught (e.g. if all the bone names are the same).
In a CFG, the line that specifies the mesh generally looks like this and should come after skeleton assignment:
If you notice that the mesh behaves strangely, first check the CSF being loaded in the CFG is the one you used to export, then if necessary re-export and verify that the correct skeleton is being used during the export process. Strange behavior can also be caused by animations that have been exported onto or are being played back on the wrong skeleton.
If you notice just a few vertices behaving strangely, they’re probably being influenced inappropriately by a distant bone. E.g. a leg bone influencing part of the hand. This is fixed by going into Max, checking the bones for those vertices, removing any bad influences, and re-exporting the mesh.
When using hardware skinning, each individual vertex is limited to being influenced by four bones at the most. Software skinning allows for an unlimited amount, but often can only handle 1/10th the number of avatars or fewer. This limitation usually won’t have any significant consequences since it is rare to need more than four bones to influence any single vertex. In the event that a vertex does have more than four bones assigned, Cal3D will use the four most influential bones for each vertex and use those for the hardware skinning.
Morph targets follow most of the same rules as regular mesh exports, and are exported through the same dialog.
Before exporting your morph target(s), you’ll need:
The vertices of a morph target work as a target position for each vertex of the base mesh. Morphing is always done relative to the current position of the vertex, rather than an absolute position in the world. This 1 to 1 repositioning is based off the vertex’s internal ID number, so, both the original mesh and the morph target must have the same number of vertices and the exact same vertex order. In other words, morph targets should be made from a clone of the original mesh. Making cuts, detaching faces or merging any objects will render the object invalid as a morph target because these affect the vertex order and vertex count.
Once you have your morph targets made, add a Morpher modifier underneath the Skin modifier on your original mesh. While this is not necessarily required for making morphs, it allows you to place them off on the side and test them from within Max. If it works correctly in the Morpher modifier, it should also work correctly in a Cal3D avatar.
Since exported morph targets are dependent on being paired with the correct mesh, the name of the morph CMF is usually the name of the mesh it affects + the name of the Morph target. e.g. mSkel_m021_head_smile.cmf
To export your morph target(s) from a Morpher modifier on the base mesh:
To export your morph target(s) without a Morpher modifier:
In a CFG, the line for the morph target needs to be placed directly after the mesh it affects and generally looks like this:
If you notice that your morph target fails to load, verify that it is being used with the correct mesh. There a few ways to check: A Cal3D mesh and it’s valid morph target will always have the same file size. You can also try loading the morph target as a mesh instead to compare vertex counts and verify that nothing extra has been added or taken away.
Hardware skinning is not compatible with morph targets, but can still be used as long as morph targets are not currently active. While a morph target is being used, the avatar will shift into software skinning automatically. Since hardware skinning allows for significantly more avatars (often as much as 10x as many) morph targets should be used sparingly. Consider the use of facial bones for talking and expressions instead of morph targets.
Unlike other parts of an avatar, materials are not dependent on being used with a specific skeleton. They aren’t tied directly to a specific mesh either. In fact, materials can be exported completely independently from the rest of an avatar. Even though the same material can potentially be used on multiple meshes, you may still want to name each material after the mesh file it goes with, and just point it to the relevant texture file. It is also useful to add the ID number into the filename for later reference. e.g. mSkel_m021_mat0_head.XRF
Also unlike other parts of an avatar, it is much more ideal to use the plain text version of a material than the binary version. That is, export as XRF instead of CRF. Material files only carry a tiny amount of data, and most of it is easy to modify. It’s usually more efficient to make a copy of an existing material and edit it to point to another texture than to export a new one.
Before exporting your material(s):
To export your material(s):
In a CFG, material IDs are assumed automatically by the order in which the materials are listed. Whatever material is listed first will be used as material [0], the second will be material [1]. Meshes only store the ID number of the material they use, so having the right order is important. This is why it is beneficial to include the material number in the filename of a material file, and keep them consistent across all avatars in a set. E.g. mSkel_m021_mat0_head.XRF. Materials can be placed anywhere in the CFG file, but it is common to place them after the section for meshes. In some cases, you may need to use a placeholder to keep numbering consistent if an avatar doesn’t take advantage of a particular slot. That generally looks something like this:
There are just a few things that can really go wrong with materials. You may find that your material doesn’t show up, which usually means either a missing texture or a mesh that was exported before IDs were assigned to materials. If you are not using shaders, you can also have very strange looking lighting that can be caused when the specular color is white. This is just an artifact of vertex shading, so you should set the specular color swatch to black.
If you have a large library of animations to use in your project, they can be one of the more time consuming parts of the export process. This is because exporting an animation takes several steps. Manually exporting even a hundred animations for multiple skeletons can potentially take days. For this reason, it is strongly recommended that you either use a MaxScript to automate the process, or mimic mouse and keyboard interaction with a tool like AutoHotKey.
Before exporting your animation(s), you’ll need:
Animations in Cal3D are generally a fairly solid translation of their Max counterparts, but do have a couple limitations. To export your animation(s):
In a CFG, animations always need to be specified after the skeleton they affect and are usually placed last in the file. In some cases the list of animations can be very long (i.e. 100+ items), so placing them at the end makes it more convenient to modify the lines for skeletons, meshes and materials. Animations in a CFG generally look like the following, and sometimes are separated into categories as well (see CFG section):
The two most common problems encountered with animation are bad skinning and loading an animation onto the wrong skeleton. Bad skinning happens when a bone is inappropriately affecting a vertex on an unrelated part of the mesh. For instance, if the femur from the left leg is having an effect on the right shoe it can cause the vertex to pull away from the rest of the mesh when the left leg is moved. In some cases, the effect can be subtle so it is useful to have a diagnostic animation purely for testing skinning that moves one bone at a time. You’ll want to turn on the wireframe and look at the model from multiple angles to be sure you haven’t missed anything. Once a badly influenced vertex is discovered, the solution is to go back into the skin modifier in max, select the individual vertex, set the weight for the bone causing the problem to zero, and re-export the mesh.
Unlike bad skinning, using the wrong skeleton is almost always extremely obvious. In many cases the avatar is stretched out into absurd and monstrous shapes. Even in the more subtle cases you should notice the proportions of the model changing in weird ways. For an easy demonstration of what this looks like, try loading an animation exported for a male skeleton on to a female one, and vice versa.