Open topic with navigation

Vizard 8 » Content Creation » 3D Models » Cal3D Workflow » Building CFG Files

8.1

Building CFG Files

CFGs are plain text files that communicate what files make up each avatar. It is the only file that needs to be directly added to Vizard; the rest are loaded based on what is written in the CFG. This section demonstrates the use of CFGs by providing both a simple example and a more complex one. The examples here can be used as templates when making your own CFGs.

CFG Template - Simple Example

Here is an example of an extremely simple CFG file. In this case, the avatar has one mesh with two materials and a couple animations. This level of complexity would be suitable for a simple background character.

Notice that the name of the skeleton appears in the name of each file that relies on it, and that the materials also specify which ID they go with. Neither are necessary for having a Cal3D file work, but following a similar convention is strongly recommended to minimize user error and keep project files organized.

One other thing to note is that the materials are being stored as XRF instead of CRF. This is recommended for materials because each one is just a few lines of XML so storing them as plain text allows for easy editing without any cost to performance.

As with python script, a # sign is used to include comments. In CFG files, comments need to go on their own line.

AdultMale_Worker001.cfg:

CFG Template - Complex Example

Here is a more elaborate example. This avatar features:

• Assets organized into named folders
• Facial morph targets for multiple expressions (morph targets are specified directly after the mesh they affect)
• A removable head, so other heads may be swapped in
• Specified bones for the neck, head and jaw which can be used for scripted head-looks and jaw-flap lip syncing
• Animations broken up in to multiple sets by similarity, separated by subfolder
• Placeholder animations, which allow other animations to be added in the same groupings while isolating the amount of renumbering that would need to be done by programmers. This should be a very short file that is different from the idle or base pose so it will be obvious if it is accidentally loaded.
• In this case the placeholders add just a small amount of breathing space and make sure each set of animations is based around multiples of five (easy to count). The amount of placeholders used should be dependent on the size of your project and a few more than the amount you actually expect to need.

As with the previous CFG file, the naming convention shows what set of avatars these parts belong to: high poly male avatars.

CC2_m001_hipoly.cfg:

Scale

Earlier versions of the Cal3D exporter required scale adjustments to be made in the CFG file. However, in the current version of the exporter this scaling is performed automatically upon export. Please note that new exports are not compatible with old exports without a workaround.

For all but the largest scenes, Max works best with the System Unit set to either centimeters or inches. Note that Max’s System Unit is not the same thing as Max’s Display Unit. It may be tempting to set 3ds Max to 1 unit = 1 meter, since this is what Vizard uses. Unfortunately, this causes some issues to occur in Max. This makes relatively small objects like humans and props difficult to work with.

When the System Unit is set to meters:

• Spinners tend to advance their numbers too fast for precise work
• The viewport camera zooms too fast and imprecisely
• Significant clipping issues occur when trying to get close to a model
• Other unexpected and annoying behavior can occur as well

It is best to work with 1 unit = 1 cm or 1 unit = 1 inch. Your display units can be whatever you want since these do not affect the actual scale of the model. In current versions of the Cal3D exporter, the model is automatically rescaled to Vizards units regardless of the units used in Max. As long as the model is the correct size in Max (e.g. 6 feet tall), it will appear the correct size in Vizard.

The scale command can still be used to create slight variations on model scale. Just keep in mind that Vizard does not do any retargeting, so this can cause animations that interact with props (e.g. door opening) to miss their targets. To prevent strange behavior, the scale factor should always be specified before the skeleton:

Flip Texture

In earlier versions of the Cal3D exporter, it was sometimes necessary to flip the UVs with a command in the CFG if certain file types were used. This feature is no longer necessary because Vizard now automatically detects when an image that would need to be flipped is used. All images should be stored right-side-up, or in other words, the same way they appear in Max.

There is variation in the order that different image file formats store their data. Some store it starting in the upper left corner, some in the bottom left. Cal3D does not currently make assumptions about the data order, so flip_texture is often used to make sure that maps come in with the correct orientation. Typically, formats like JPG, TGA and PNG need to be flipped, while DDS does not. If your texture appears to be coming in upside down compared to the max model, adding a flip_texture line is the first thing to try. If you open an older file and the texture appears upside down, someone may have tried to correct the flipping by editing the image itself.