Last Modified: Tuesday, 23-Feb-1999 15:08:47 CST
You may choose to do this programming assignment and do a smaller final project.
The goal of this assignment is to give you a little experience in dealing with motion capture data, forward kinematics, and angle representations. Doing this assignment can give you a basic framework for a range of projects in doing motion processing.
Your task is to write a program that:
The assignment is intentially left a bit open in terms of the details. Some minimums are given, and you must do "more than the minimum" in at least one category. Specific "Bonus" part suggestions are made in the details sections.
You may write your program in any language (C++, MATLAB, Java, ...), have it run on any computer, with the caveat that you will have to give a demonstration.
You must document your assignment on a web page.
You are allowed to use any software libraries that we have access to. For example, you might find Quaternion and Euler angle code on the web, or use some linear algebra code. You must cite any code that you did not write in your documentation.
You must do at least 1 of the "Bonus" parts.
Your program must be able to read in motion capture data in either the Acclaim format (which is documented at the BioMechanics web site) (called .asf and .amc files), or the Biovision Hierarchy format (.bvh files), which is not documented, but is a simpler format. In the ~cs838-3/public/Motion directory, I will put examples in both formats. I recommend you try the bvh format, since there are literally hundreds of sample motions available.
Both file formats contain definitions of the structure of the skelleton and the actual data for the parameters.
Your data parser does not have to be totally general. If you want to make assumptions about the form of the skelleton (for example, that it always has 2 arms, that the joints are Euler angles with XYZ rotation order, ...). This means that you can probably ignore the "hard parts" of parsing the data files, and hard-code it.
However, 1) you must document your assumptions, and 2) you must be able to provide at least 2 example files from the Motions directory that your program works with.
You should keep the Euler Angles internally so you can do step 5.
Beware: lots of the files were created on a PC or Mac so they might have end of line issues. You can use dos2unix (available on CS Unix machines), or make your program smart (the latter is, of course, preferred).
BONUS: make you program read and write both formats for any skelleton, so you can do conversions.
You must be able to display the data that you just read in. There are two general ways to do this:
Your pictures do not need to be fancy - "block" figures are OK - however, the display must be good enough so you can see what is going on. Nicer pictures will be appreciated.
Here is an example from a system I wrote. The "blocks" are ellipses (they look nicer). Notice the orange "traces" (see Part 3). This example also uses "strobing" where I show every nth frame (using transparency). Another thing here is the use of a groundplane and "hack" shadows (created by simply redrawing everything with the height scaled to 0).
BONUS: do "automatic cinematography." Where the camera positions
(and maybe even a camera motions) are computed based on where the
motion is. Describe your scheme for determining this.
Example: in looking at a walking motion, your program could have a
button that gives a "profile" view of the whole motion and another
button that had the camera follow the character in a tighter
shot.
Your program must be able to compute the end effector positions. You can demonstrate this by displaying a "trace" of where the end effector goes over the course of a motion.
BONUS: do inverse kinematics. Allow the user to grab a hand or foot and drag it around. This is a big deal since you also have to create a 3D user interface.
Have your program store Quaternions in addition to Euler Angles. This will require you to be able to convert in at least one direction. You should have ways to look at both the Euler Angle and the Quaternion motion (and to compute the forward kinematics for each). Although you should be able to switch, the results should look the same (until we get to part #5).
BONUS: do exponential maps (as in Grassia) as well. (and use it for Parts 2,3, and 5).
To this point, there is no interpolation involved.
You should allow the user to specify a beginning and end frame, and rather than playing the frames in between the two frame, interpolate them (using linear interpolation, or slerps for the quaternions). That means that there are 3 different things that you need to look at:
You should find examples where #2 and #3 are different, and make sure you have some way in your display to show the difference between the results.
BONUS: Add some kinds of cubic interpolation (for example, Catmul-Rom, Hermite cubics where the derivatives are estimated by looking at the neighboring samples, ...). Doing the cubic interpolation for Quaternions will require you to look at the paper in SIGGRAPH '95.
BONUS: do "automatic key reduction" - that is, write a procedure that determines a set of poses to be interpolated that comes close to recreating the motion. The goal is to find as small a set of keys that work within an error bound. For example, your system might try interpolating segments of increasing length until it exceeds an error bound (interpolating from 0->9 is OK, but 0->10 has per frame error that is too high, ...)