Project 2: Motion Path Editting

The purpose of this project is to give you some experience dealing with motion capture data, to experience the issues in using file formats for motion data, to gain intuitions about how motion editing techniques work, and to work through the details of an animation methodology from a research paper.

The Basic Idea

You must write a program that reads BVH files (a standard skeletal animation data file format) and displays them in an interactive viewer. You must implement a variant of path editing to allow the user to alter the motion. You must implement some kind of motion blending and the ability to concatenate motions (play motions one after another).



Ground Rules

Your program must run on the Windows machines and using OGRE3D. You may use utilities and libraries that you find, subject to approval. Any "borrowed" code must be clearly documented. Copying someone's assignment from a previous year is not OK.

Reading Files

Your program must read "Biovision hierarchy files." In the webpage motion data, you will find lots of BVH files to experiment with. You will see all sorts of different skeletal configurations, joint types, and other variations of the file formats. In the ideal world, you would be able to read any BVH file we threw at your program. More realistically, we would like your program to understand some subset of them. The larger the subset, the better (and this will be rewarded in grades). Some ground ground rules:

  1. Your program should not crash on a file that it cannot understand.
  2. Your program must read at least 5 of the files in the Motion directory. You can pick the 5.
  3. You must, in your documentation, describe the limits of the reader. It is much better to say "my reader only supports ZXY euler angles for joints" than to have a reader that mysteriously doesn't work some times.
  4. Some reasonable simplifying assumptions you might make include: supporting only certain types of Euler angles, or only supporting a fixed topology. (the latter is a severe limitation, and I do not recommend it).
Displaying Motion

You must provide an interactive viewer for displaying the motions that you read in. Your viewer should use OGRE to display things, and provide the ability to play the motion at "frame rate" as well as the ability to "scrub" (interactively move through frames). You must provide some interactive camera controls so that the user can control the view.

The nicer that you draw things, the better. Drawing lines between the joints is the easiest, but drawing some "bones" (like ellipsoids) looks a lot better. Skinning looks the best, but that's a really advanced feature.

  1. You should do some things to help make the motion easier to see - for example, drawing "traces" that sweep out the paths of the end-effectors, or strobes (drawing several frames simultaneously). Try being creative in given tools to help the user visualize the motion.
  2. Drawing a groundplane and shadows are an easy way to make things look a lot better.
  3. You program must be able to place the camera in a position where it can see the whole motion (this requires you to figure out the spatial extents of the motion). The better your program does at this, the better.
  4. A nice advanced feature to add is a tracking camera that follows the character as it moves. This take a little thought to do well - it can't be too bouncy, or spin too fast, ...
  5. You must put in a timer to control framerate. Your program must offer the option of displaying animation at 30fps. You might want to allow other options (like just blasting the animation as fast as possible, or allowing for slow motion viewing).
  6. Your program should also support showing 2 (or more) motions at once. This will be useful for when two characters interact, as well as for comparing motions (which you will need to do).
Forward Kinematics

Your program must compute the forward kinematics. That is, you must be able to compute where each joint goes, and have some way to show that you can do this. For example, you might want to draw a "trace" line showing where the point goes.

Path Editing

You must provide the user with a way to edit the path of the motion (e.g. if the character was walking in a straight line, you can bend it and have it walk along a curve). The paper on path editing is here. Note: this is not a paper we will be discussing in class. Part of the exercize is for you to learn how to read a technical paper, figure out how it works, and try it out. While I am biased (I did write the paper), I think that this one isn't too hard.

Path editing has a lot of variants. Start with the most basic, and then add features. The most basic version (ignoring orientation) should be trivial. I expect that most people will be able to get the orientation control. Arc-length parameterization (you'll understand what I'm talking about after you read the paper) is clearly an advanced thing. Putting in some kind of IK solver to cure foot skate is a very advanced feature (but there are some simple ways to do it that might make it not so bad).

There are many other possible extensions to path editing to try. For example, you might determine when the character is in the air, and make sure the path doesn't bend (ideally, you could stretch the path in such a case). You might mark parts of the motion that are not allowed to be path editied (for example, when a character stops to pick up an object).

Rigid Transformations, Concatenating and Blending

You need to be able to apply a rigid transformation to a motion before displaying it. This will be important for blending and concatenating. You should have some interface for manually

You need to be able to play a sequence of motions one after another. This involves applying the transformation such that the end of one motion is the beginning of the next. We will provide you with examples of pieces of motion that simple "snap together" - you will be able to make loops and whatnot using them by playing one after another. You might want to be able to set up your interface so that you can load in a bunch of motions and play sequences of them.

You need to be able to blend 2 motions together (with varying blend weights). For example, to make a transition between one motion and another. This means that you must be able to rigidly transform motions (so that they line up well enough) and time shift things. If you want to do better (implement time warps or something that's a bonus).

Note: the blending can be completely manual. However, you must be able to position the two motions relative to one another, and set the time shift.


You must turn in all files required so that we can run your program, documentation on how to use your program (including a description of limitations), and a description of your programs features.


The basic project would include:

  1. Reads many BVH files, with some restrictions
  2. Be able to read in 2 BVH files simultaneously and show them together.
  3. Displays ellipsoids or other rigid shapes for bones
  4. Places the camera automatically, and gives a camera user interface
  5. Implements basic path editing (with orientations handled correctly)
  6. Is able to position motions (under user control) and concatenate and blend them

It is better to have a project that does all of the basic features and works well, than to have a project that has some fancy, advanced feature, but fails at the basics.


An advanced project might add:

  1. Read almost all BVH files
  2. Display nice character geometry
  3. Have a good camera UI that includes tracking
  4. Implements advanced path editing (arc-length parameterizations)

Above and beyond the call of duty projects might:

  1. Does better alignment methods (registration curves, time warps), or automatic methods to find alignments
  2. Has some methods for choosing which motions to concatenate (interactive control, random walks, ...)
  3. Implement Inverse Kinematics to clean up footskate
  4. Do smooth skinning
  5. Provide other motion editing features
How will we grade it?

You will have to provide a web page documenting the project (details to follow). You will also have to give a in-class demo of your project.

What to hand in?

By the deadline (November 11th, 11:59pm) you must turn in:

  •  Everything needed to compile your program (.cpp files, .H files, .vcproj files, .sln files, and UI files or other things your program needs). Be sure to test that your program can be copied out of this directory and compiled on a Storm computer.
  • Your README file.
  • Three screen shot (or two) showing off neat things in your program.
  • A video of your program.

Dobromir Todorov - Dobry, Motion Path Editting -- Dobry


Chun-Wei Wang, and Fu-Tsung Yang, Motion Path Editting -- PP and Alex


Hsing–Yu Fu, and Pei–Ching Li, Motion Path Editting--Hsing–Yu Fu、Pei–Ching Li


Kuang-Yi Chang, Motion Path Editing - Kuang-Yi Chen


Yueh-Ju Sung, and 何芳琳, Motion Path Editing--宋岳儒、何芳琳


Ridho Rahman Hariadi , and Christian Wijaya, Motion Path Editing- Rihdo and Christian


Chun-Wei Wang, and Fu-Tsian Yang, Motion Path Editing -- Chun-Wei Wang and Fu-Tsian Yang


何柏輝, Motion Path Editing - 何柏輝


Dobromir Todorov - Dobry, Motion Path Editing-Dobromir Todorov - Dobry


Ibnu Febry Kurniawan, Motion Path Editing-Ibnu Febry Kurniawan