A CAT rig is a collection of Controllers that generate motion data for Max nodes. The concept is that CAT is simply a specialization of the functionality that Max already provides.
The controllers are specialized to the job of each particular body-part. For example, we have a specific controller for the collarbone, a specific controller for spine bones, and a specific controller for digit bones. Generally each class handles a particular job and only that job. A hub may be a pelvis, ribcage or head, but that is because the functionality is the same for all these parts.
The CAT Rig is rooted in the CATParent. This entity is not part of the rig at all, it is simply a visual container for a set of data and functions that apply to the rig as a whole. The CATParent is not the root of the hierarchy, it actually has no functional impact on an animated CAT character. It is just part of the scene to give users a logical place to access CAT data.
In CAT, we have tried whenever possible to use Max classes instead of implementing our own. We do not implement any actual animation classes (eg Bezier Float, Position XYZ), we simply use Max implementations of these classes.
The original goal of CAT was to build a rigging system that was independent of any one scene size. We wanted to have a system that could be easily resized. To enable this, we implemented CATUnits. CATUnits is a scalar value stored on the CATParent that is used to scale most rig-specific data (eg bone size, setup positions, etc). Animation data is not scaled by CATUnits.
CAT works in two distinct modes. In setup mode, operations on the rig are intended to change its base properties – object size, length axis, CATUnits etc. In Animation mode, only animation data should be changeable.
When CAT was originaly designed, CAT bones were based on Max primitives and the Max Coordinate system. With the Z-axis in Max being "up", it made sense to use the Z-axis as the length axis for CAT Bones. However, this presented a problem when some physics engines required exported character bones to be aligned on the X-axis. The X-axis preference by game engines, 3ds Max, Maya and almost every 3d animation tool out there originated from the older field of robotics where the Denavit-Hartenberg conventions defines X as being the dominant bone axis.
CAT version 2.0 added the option of using X as the length axis. This introduced a 'length axis' setting used by IK solvers, spine, geometry builders, copy-paste tools etc. Visually, there is no difference between them when switching. However, you might note that when creating a CATParent via MaxScript, that it is tipped over on its side. This is because the mesh defaults to being X up. The mouse creation tools compensate for this by rotating the node over so its X axis aligns with the scene Z axis, but when creating via MaxScript the matrix set is the identity, and the X-up mesh appears to be lying sideways.
All animation data in CAT is stored in its layer system. The basic CAT rig classes provide functionality, and their Layer controllers provide data. Each CATControl has 0-N layer classes to store its data of either Matrix3 or float type. The CAT layer classes just store lists of Max animation classes of the appropriate type. The layer system is controlled via means of messaging (see CATMessage below). The messages are passed to individual layer controllers, which then take appropriate action to add/remove layers. The CAT rig elements know nothing about the layers, and simply query the layer controllers for the appropriate values. The Layer system merges the values returned by the stored animation controllers according to the type of the layer system and its global weight value.
Each layer in CAT is one of these types: Absolute, CATMotion, Relative Local, and Relative world.
The main class for working with the layer system is the CATClipRoot, stored on the CATParentTrans. The cat clip root is responsible for managing the layer system. It stores a list of classes containing meta-data describing each of the layers called NLAInfo. The NLAInfo class stores all the information on what a layer is for, such as its type, name, colour, etc. The NLAInfo also stores a pointer to a float controller for the timewarp of the layer and an instance of the CATClipWeight class for generating the global weight for the layer.
A CATClipValue needs to scale each value in its list by a weight. To do so, it needs to know the global weight for the layer (stored on the CATClipRoot's NLAInfo). It also needs to know what the local weight for the current group is. Each group generates an instance of the CATClipWeight class, and a pointer to this instance is shared by all CATClipValues in this group. The CATClipWeight also stores a pointer to the CATClipWeights class applied to the groups parent. Eg, for the limb group, its weights controller would store a pointer to the owning hub's weights class. To generate the final weight for a layer value, the global weight is multiplied by the local weight and by the parent's local weight. The parent's local weight will have been multiplied by its parent's local weight - in this way the weights are inherited by each group.
CAT provides custom CAT objects for rig elements. A CAT bone provides no functionality; it is simply a visual aid to help show how far away from each other bones are. There is a dependency between the controller and the bone, but we could probably remove that dependency and never notice. For the majority of work, it is not necessary to work with the CAT bones.
CAT provides a variety of ways to extend the built in rig structure:
ArbBones : An arb bone is a generic CAT Bone. It has all the functionality of standard CAT Bones, including stretching, layers & weights, etc, but has no functionality specific to any body part. Users create these arb bones generally to extend the rig. Their only use is as bones though, as they rely on the CAT objects (and CATObjects are not replacable).ArbBone controller without a CATBone attached.