Project 1:
Motion Capture Display and Editing
The purpose of this project is to give you some experience dealing with
motion capture data, to experience the issues in file formats for motion
data, to gain intuitions for 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), writes them back out, and displays them in an interactive
viewer. You must implement a variant of path editing to allow the user
to alter the motion.
Ground Rules
You are to work on this project in groups of 2. If you want to work in
a group of 3, that will be allowed ONLY if there is nobody who is stuck
without a partner.
Your program must run on the Windows machines in B240. Other than that,
you may use whatever tools you want to build your program. Write it in
C++, Java, Matlab, or whatever you want to get the job done. Personally,
I suggest using C++ and FlTk and OpenGL.
If you are going to incorporate something other than a basic graphics/UI
library (like OpenGL, FlTk, or GLUT), please ask me. Generally this is
OK, but I want to make sure you actually implement the parsing and display
code.
The project is due on TUESDAY, MARCH 5th. The late policy is as follows:
you may turn your project in late, without penalty, any time before the
project demo time. This project demo time will be no earlier than Wednesday
March 6th. We will take a class period, go down to B240, and play with
everyone's projects. Probably on March 6 or 8, depending on how class
is going.
Even the basic version of this project is pretty big, and completing
the basic version well will get you a pretty good grade. So please do
not procrastinate. There is a lot of code to be written, and a lot of
stuff for you to learn. (Alex wanted me to warn you that this project
might be bigger than it seems).
Reading Files
Your program must read "Biovision hierarchy files."
Motion capture file formats are documented in a set of notes
by Jeff Thingvold (now at Motion Analysis). These notes are 3 years old,
but they are still useful. The BVH file format documentation is somewhat
vague, but its a vague format. The "original, official" specification
was some hand sketched notes by some people at BioVision (I have a copy
of those notes, and they aren't too helpful).
In the directory p:/graphics/public/Data/Motion, 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:
Your program should not crash on a file that it cannot understand.
Your program must read at least 5 of the files in the Motion directory.
You can pick the 5.
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.
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).
Your program must be able to read the files that it writes.
Displaying Motion
You must provide an interactive viewer for displaying the motions that
you read in. Your viewer should use OpenGL 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.
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.
Drawing a groundplane and shadows are an easy way to make things look
a lot better.
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.
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, ...
Writing Motion
Your program must write data out as a BVH file. This is only interesting
after you've implemented some stuff to change motions around.
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
exersize 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).
Requirements
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:
- reads many BVH files, with some restrictions
- displays ellipsoids or other rigid shapes for bones
- places the camera automatically, and gives a camera user interface
- implements basic path editing (with orientations handled correctly)
- write out the results of path editing in BVH format
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.
A really advanced project might add:
- read almost all BVH files
- display nice character geometry (with skin deformations around the
joints)
- have a good camera UI that includes tracking
- implements advanced path editing (arc-length parameterizations)
|