Depending on the system you are using, you will have to deal with several different motion data file formats. Real-time systems usually generate a stream of data that can be used directly in the animation software with the help of special plug-ins. Some optical systems' data is also generated in real time but in most cases it is not, so it won't be streamed into the animation software, but rather imported from a data file. Most computer graphics packages such as Maya or three-dimensional Studio Max already have converters that will allow you to import data files in several file formats, but for the sake of character setup, it is important to know what data items the files contain. In addition, none of these files has any information that pertains to the deformation of the character's surfaces, but rather the mechanical aspects of rigid segments. All deformations are specific to the animation software to be used.

All these data files go through a few stages before becoming final. First, as the data is collected a stream file is created. This is what we call raw data. In the case of optical systems, a file is created for each of the system's cameras containing the raw images in a format specific to the manufacturer. It may contain just black-and-white or grayscale images, or maybe no images at all but some smaller representation of the camera's view of the marker cloud, like a series of 2D coordinates. If this is the case, it means that the camera did some processing of the images before sending them. This is done to accelerate the process and it is part of how optical systems today can achieve some kind of real-time feedback, but the downside is that the system doesn't keep the data in its original form. These files are the ones that, in combination with a file containing the calibration of the capture volume, will be used to track the 3D data.

The second stage is the file generated after tracking the position of each point, which contains the Cartesian coordinates of each of the markers. The data in this file is called global translation data, as it represents the position of each marker in reference to the world origin, without including any hierarchy or skeleton definition. I will refer to this type of file as translational, because it contains no rotations, only translations of independent points in space. This type of file can already be used for performance animation, but there are other levels of simplification: files that contain data based on segments or limbs rather than points. There are two data types that meet this description, the hierarchical segment translation and rotation and the global segment translation and rotation. Both of them are based on a definition of a skeleton to be used for driving the motion of the character and are created by combining the points in the translational file. In the hierarchical rotational file, mostly the root point has rotations and translations and the rest have only initial local translations that define the length of each segment, plus a stream of local rotations. There is also a set of scale channels that represents the variation in length of each segment. This is necessary because the segments are not exactly rigid, as the markers have to be placed over skin or clothes. This channel also helps in the determination of data accuracy. The global rotational file contains translations, rotations, and scale channels for each independent segment, and there are no dependencies between them.

Rotational files are generally easier to use than translational files because most of the work in setting up a skeleton has already been done; however, translational files allow you to create better and more complicated character setups. Only experienced users should work with translational data. In addition, because translational files contain no rotations, they are less prone to common problems associated with Euler angles' transformations.

For many years, the primary data file format used for optical motion capture was the Acclaim .amc and .asf combination, but today it is the .C3D format. Other file types used are the Biovision .bva and .bvh files and the Motion Analysis .trc and .htr formats. Many companies have special file formats that fit their particular needs. At Tsi, for example, we had the .tsi file, a binary file that was better suited for fast random access, an essential item in video games and data editing tools. Some of these files are rotational and others translational and they're all delimited by tabs. We will later explain each one in detail.

Bringing these files into animation software successfully is not always as easy as it seems. Many times, the file has to be prepared with certain constraints based on particularities of the individual animation program. Other times, the program has to be configured in a certain way to be able to receive the data properly. The first usual restriction has to do with world space. Some animation programs like Y to be the axis going in the up or down direction, while others like Z. Some consider XY as the front plane, while others use XZ. Another common difference between off-the-shelf animation software is the order of transformations and the order of rotations. Most animation programs have a hard-coded order of transformations, others have a hard-coded order of rotations, and the data file must be prepared accordingly. It is not enough to change the definitions in the file; the data must be recalculated as well. One more item to consider is the base position, as some programs require their initial skeleton's zero pose to be aligned in a certain way. In addition, the segment scale specified in some files is totally ignored when the data is imported into some animation programs. Other restrictions include naming convention and units. The easiest type of data to import is the translational, because, since no hierarchy and rotation or scale channels are present, most of the restrictions are not applicable. The down side of importing translational data is that the character setup is much more involved, but, on the other hand, you have better control of what you want to do with the setup.

Most animation programs support at least one motion capture format and it is really unlikely that you may ever have to write your own translator. This section is for you if you are interested in how things work under the hood. The language and platform are not relevant to our discussion, but I will use the C language to illustrate the programming steps. I will also present the code in a sequential way as opposed to modular, as I believe the continuity will aid you in the understanding of the logic. If you decide to write your own translator, you may want to use more functions and subroutines or an object-oriented language such as C#.

As a case study, we will use the .htr format as the input file and the Acclaim format as the output file. I chose Acclaim as the output format because it is the most complicated one that is not binary.

The first step in creating a translator is to define a buffer that will hold all the data of both the input and output files. The .htr file buffer looks like this:

htrFile, a variable of type struct hrtFormat, will end up containing the whole data in the .htr file. The first twelve variables in struct hrtFormat correspond to the .htr file's header section. ChildandParent is a buffer that will hold all the child-parent pairs as defined in the SegmentNames&Hierarchy section. This buffer is of the previously defined type struct htrSegmentNamesandHierarchy, that will hold both child and parent strings. BasePosition will contain all the data in the BasePosition section. It is of type struct htrBasePosition, where the segment and initial transformations are defined. Finally, SegmentData, of type struct htrFrame, will hold the motion data.

The output file is actually a combination of both .asf and .amc files and we can define its structure as follows:

acclaimFile will hold all the data in the .asf and .amc files. It is of type struct acclaimFormat. The bone information will be located in boneData, while hierarchy will hold all the parent-child relationships. frameData will contain all the data from the .amc file. Notice in the definition of struct acclaimBoneData that the integer variable dofNumber doesn't actually come from the .asf file. It will contain the number of degrees of freedom available for each particular segment, so that the dof line will be parsed only once per segment. Another special purpose variable is the infinity integer inside the definition of struct acclaimBoneLimits, which, as its name says, will hold a flag to indicate infinity. struct acclaimHierarchy will hold the hierarchy data in pairs of parent and child, as opposed to the way the .asf file holds it, with a parent and all of its children in the same line. If the parent has several children, more than one pair will be generated.

If you compare the aforementioned definitions with the actual file structures as explained in the previous section, you will find that most of the variable and type names are very close to those in the files themselves. You will also find that the structures contain more information that will be used in the conversion from .htr to Acclaim, but including it in the data structure is good practice in case you need it in the future.

The next step is to start reading the information from the .htr file into the data buffer. Assuming a file is available and its name has already been processed by the program and placed in the string htrFileName, we proceed to open the file and then process the header section:

Now we proceed to load the SegmentNames&Hierarchy section into the buffer. The next step after finding the section is to allocate memory for the branch that will hold this data. We can do this now as we already have loaded the number of segments that we need to process.

We continue with the base position section. We are now looking for eight tokens per line that represent the segment name, all six transformations and the bone length.

The last step in loading the .htr file is the processing of the actual segment data. It also consists of eight tokens, but there is one set of data per frame for each segment. We must allocate space for htrFile→segmentData based on the number of segments, and htrFile→segmentData→frame based on the number of frames.

We have loaded all of the .htr's file data into memory. At this point, we will start porting the data into the Acclaim format buffer. We could write the data straight into the .asf and .amc files, but moving it first into the buffer will help illustrate this operation in case we decide to write a converter from Acclaim to any other format in the future. If we end up writing a more complicated application where we can port data between several formats, we could perhaps have a different kind of generic buffer where we could save data from any of the file formats. This buffer could be designed in a way that would facilitate other operations as well.

We now write the root section. The order of transformations in the .htr file always includes translations first and then rotations, followed by scale. Because of this, we will assume all translations to occur before all other transformations and include code only to process different rotation arrangements. We also save a predefined rotation order value in htrRotOrder that we will use later, as the .htr file uses one single order of rotations across the board, as opposed to the Acclaim format, where each segment can have a different one.

The .htr file uses an actual segment as the parent of all the hierarchy. In the Acclaim format, we will move the hierarchy one step down, leaving the .htr's parent node as a child of the root node, and we will leave the root node at the origin at all times. This is very useful because we can use the root to add a transformation offset to the whole tree if desired. We could also do this at the animation software level by adding a parent node, but if we are dealing with a great number of motions, it is better to offset all the motion data files.

We start saving the bonedata section. We assume that all segments are initially located at the origin, and the length axis is pointing in the GlobalAxisofGravity direction. This part is where some variation can exist between animation software packages, as not all of them assume this to be the initial position of bones. A more elaborate translator should include switches to deal with these software peculiarities.

Even though the Acclaim format has the ability to select which transformations are available per segment, we have to include them all, as the .htr file includes all seven transformations for each of the segments. The limits will also be left open, as these are not supported by the .htr format.

The hierarchy section in the .asf file is quite different from that in the .htr file. The first one lists a parent first, followed by all its children in the same line, while the latter lists each child first, followed by its parent. The number of lines in the hierarchy section of the .htr file is equal to the number of segments, while in the .asf file it is equal to the number of nodes that have children, without counting the root node. This is why, before starting to save the hierarchy in the Acclaim buffer, we must find out how many segments have children.

We now start saving the data stream. We will not worry yet about the order of transformations. These will be dealt with when we write the .amc file. The l channel in the .amc data is not the same as the SF channel in the .htr file and it must be converted before saving. SF is a scaling factor or a multiplier for the initial segment length, while l is a translation. This means that an SF value of one is equivalent to an l value of zero. To convert the scaling factor to a translation, we multiply the initial length by the scaling factor and then subtract the segment length, obtaining the difference in length between the initial length and the length for the frame in question.

We have now saved all the data in the .htr file into the Acclaim buffer. The next step is to write the actual .asf and .amc files. We saved the number of segments in a variable named numBones and the number of frames in numFrames because the Acclaim format does not include a number of segments or frames field.

As we write the motion data, we must deal with the order of transformations per segment. We will use the dof field to determine the order per segment.