Before the process of parsing and interpreting motion capture files can begin certain tools need to be in place. If you spend a little time creating these tools you will find them extremely useful in all your file IO work. Complete code examples are not included here but from these descriptions it should be a simple matter to construct them.

Most motion capture files are ASCII (the only one that isn't is the tracking format C3D) so the creation of a good line parsing routine should be your first project. I have a function called parse_string() which takes the string as input and returns an argv, argc list just like you get from the main()function. This routine separates tokens on a line much like is done in a command shell where the characters "{}[](),;" are always returned as a separate token and the rest is just space delimited. I've never needed any more than this to parse a motion capture file.

There are a number of references you can use to help you create your math routines that you will need to effectively handle the motion capture data. At various times you will need to represent rotation data as a matrix, quaternion or as Euler's angles. So you will need to create conversion routines between these different representations. Also, you will need to construct transformation matrices of translation, rotation and scale values; to multiply matrices together, to take the inverse of a matrix, to multiply a vector by a matrix and to decompose a matrix into its constituent parts of translation, rotation and scale. Graphics Gems II, Ken Shoemake's paper on quaternions, and most any book on graphics should provide enough source material for creating these routines.

The nomenclature I use when writing math expressions is left to right. For example:

Here the vector, v, is on the left of the matrix, M, which transforms it. Saying this now avoids confusion, particularly when discussing Euler's Angles. When you encounter rotation data expressed as Euler's angles you must know the order in which the rotations are applied. This is often simply stated as "XYZ" order or "YZX" order, however this isn't enough. You must also know if the vector is on the left or the right of the transformation matrix. If X,Y and Z represent rotation matrices with just a single rotation about the given axis then the composite matrix M might be composed as follows:

or using a right to left notation you might have

These two equations give entirely different results but can both be called "XYZ" rotation order.

Keep in mind that for the Euler's angles representation many different rotation values can give the same result, 0 degrees and 360 degrees gives you the same rotation. The same is true for quaternions, a quaterion and it's negative (where each component is negated) give you the same rotation. Only with the matrix representation do you get a one-to-one mapping of rotation to representation.

All elements of motion capture file have to be referenced in some fashion. There are usually names given to each element but that isn't always the case. Sometimes the elements are merely numbered. Use the names whenever possible to store and reference your data. Often the order of appearance of names in a header section will be different from the order in the motion section of a file, do not assume that they will be listed the same way. If you allow for this you will find you have much less problems when substituting the motion data from one file over the motion data from another file but you want the same skeleton for each.

Sample rate information is given as either the number of samples per second or as the length of time between each sample. Formats which are used by optical motion capture systems always have a constant rate of sampling for their data, generally 30 or 60 samples a second. Some optical systems can achieve even higher rates of sampling. You can assume that the rate of sampling in these cases doesn't vary. This is not true for magnetic motion capture systems. The timing of data can, and usually does, change throughout the data file if you are handling the raw data as it has been acquired from the motion capture system. For older magnetic systems it's even possible for each sensor to provide different rates of data from the other sensors in the same motion capture session.

Some of the file formats will provide units information to indicate how the values should be interpreted. If you like, you can ignore the units for translation data since the difference between one set of units and another is simply a matter of scale. However, you cannot ignore rotation units because you must know the unit type before applying your rotation calculations. If the units are not given for rotation you can be comfortably certain that the rotations are expressed in degrees.