READMEFIRST v1.00 last update July 20, 2008 by B. Hahne
This READMEFIRST file accompanies the cgspeed.com "BVH conversion"
release of the Carnegie-Mellon University (CMU) Graphics Lab Motion
Capture Database. See "Where to find stuff" at the bottom of this
file for where to get the BVH conversion and/or the original CMU
dataset.
The original CMU motion capture database isn't in BVH format - it's
in ASF/AMC format. This BVH conversion release was created by Bruce
Hahne, a hobbyist animator, in the interest of making the data more
available and easily usable by other animators. I presently (2008)
maintain the web site www.cgspeed.com, where this BVH conversion
release will be available or linked.
The emphasis on this release is to produce BVH files that can rapidly
be used in MotionBuilder for motion retargetting. The files are not
yet particularly Poser-friendly or DazStudio-friendly, due to
incorrect assumptions that those programs have to make about the
underlying joint rotation setup.
ADVANTAGES OF THIS RELEASE OVER THE ORIGINAL CMU DATA:
- This release has the motions in BVH format. :-)
- T-poses: Every BVH file has a T-pose added as its new first frame.
The T-poses face the positive Z axis and are therefore MotionBuilder
compatible.
- Joint renaming: As many joints as possible have been renamed to be
compatible with MotionBuilder's joint naming conventions. This renaming
makes it much easier (faster) to use the BVH files in MotionBuilder.
- Index files: The release includes consolidated indexes that list
the motion filenames and their descriptions. Both spreadsheet and
word processor friendly index files are available.
- MotionBuilder-friendly: the joint renaming and the addition of the
T-pose make it possible to use these motions for animation
retargetting within MotionBuilder in seconds rather than minutes.
CONVERSION PROCESS:
- I started with the full set of AMC and ASF files, available from CMU
as a single .zip file
- I ran the AMC/ASF files through amc2bvh in batch mode to produce BVH files.
- I analyzed several of the BVH files in MotionBuilder to determine how
to set joint angles to set a T-pose.
- I then ran the BVH files through a Python script that I wrote to do
joint naming conversion and T-pose generation. I haven't yet (July 2008)
released this script.
- With the exception of the new frame 1 (the T-pose), there are no
modifications to the motion data itself. If the original CMU data
is noisy, the conversion will be noisy. If the original CMU data
has the actor's head moving at an impossible angle, the conversion
will do the same.
CONVERSION NOTES:
Shoulders: The CMU dataset's skeleton is somewhat annoying around the
shoulders because it doesn't use a clavicle joint, only a shoulder
joint. Also, the rotation points of the CMU skeleton shoulders are
significantly wider than the hips. The result was that when I did
some retargetting tests in MotionBuilder, I often found that the
geometry of the target character's arms would punch through the hips.
To somewhat mitigate this problem, I set the T-pose of this converted
CMU dataset such that the arms angle slightly downwards, at 5 degrees
down from the horizontal. This adjustment helps to reduce the "arms
through the hips" problem.
Fingers: CMU's main page says this about the dataset:
The "finger" and "thumb" joints are added to the skeleton for editing
convenience - we do not actually capture these joints' motions and any
such data should be ignored.
Therefore in the BVH joint naming conversion, I've maintained the
mapping "lfingers" to "LFingers" and "lthumb" to "LThumb", since these
are names that MotionBuilder's character joint naming convention does
NOT recognize. We don't want MotionBuilder to try to these joints,
since they have no data on them.
Playback speed: The CMU dataset was sampled at 120fps, however this
information apparently isn't saved in the CMU-distributed AMC/ASF
files, and the freeware utility amc2bvh simply assumes a default value
of 30fps (Frame Time = .033333) when it writes out BVH files. This
BVH conversion release fixes the problem by rewriting Frame Time to
.0083333 in each BVH file, which equates to 120fps.
INDEX/INFORMATION FILES:
Each .zip file in this BVH conversion release should include a copy of
this READMEFIRST.txt file, plus four variations of the same motion
index information:
- cmu-mocap-index-spreadsheet.ods: Open Document / OpenOffice
spreadsheet format
- cmu-mocap-index-spreadsheet.xls: Microsoft Excel format
- cmu-mocap-index-txt.txt: A simple text file with the index
information and no commentary.
- cmu-mocap-index-text.rtf: Rich Text Format index information with
some commentary.
USAGE RIGHTS:
CMU places no restrictions on the use of the original dataset, and I
(Bruce) place no additional restrictions on the use of this particular
BVH conversion.
Here's the relevant paragraph from mocap.cs.cmu.edu:
Use this data! This data is free for use in research and commercial
projects worldwide. If you publish results obtained using this data,
we would appreciate it if you would send the citation to your
published paper to jkh+mocap@cs.cmu.edu, and also would add this text
to your acknowledgments section: "The data used in this project was
obtained from mocap.cs.cmu.edu. The database was created with funding
from NSF EIA-0196217."
JOINT RENAMING TEMPLATE
Here's the joint renaming template that my unreleased Python script
uses, with a variety of comments that come from my analysis of the skeleton.
The left column is the original joint name used by the CMU dataset,
and the right column is the joint name that my script outputs. Most
of the time this right-column name is one that MotionBuilder
recognizes, however in some cases we have to intentionally convert to
a name that MotionBuilder won't recognize, because we don't want
MotionBuilder to use the joint when we characterize.
---------------------------------------------------------------------
# Some facts about the CMU skeleton:
# lhipjoint and rhipjoint are in the same location as hip, and have no
# keyframes.
#
# lowerback is in the same location as hip, and has keyframes. MotionBuilder
# docs say that Spine must NOT be in same location as hip, so we have to
# throw out "lowerback" and not call it Spine.
#
# thorax, lowerneck, lclavicle, and rclavicle are all in the same location.
# thorax and lowerneck are keyed. lclavicle and rclavicle are not.
#
# Although we have two neck joints, the CMU "lowerneck" is really in
# the middle of the spine -- it sure doesn't look anywhere close to
# the human neck to me. However when I tried calling it Spine2,
# MB gave a warning: "Hierarchy warning: LeftShoulder is not the direct
# descendant of Spine2, Spine1 was found".
#
# Per CMU web page: 'The "finger" and "thumb" joints are added to the
# skeleton for editing convenience - we do not actually capture these
# joints' motions and any such data should be ignored.'
TEMPLATE: cmu
hip Hips
# Not sure what to do with lhipjoint. It has no keyframes and is
# just a connector to attach the leg, so probably OK to rename it
# in a way that MB won't use it.
lhipjoint LHipJoint # Not used by MB
lfemur LeftUpLeg
ltibia LeftLeg
lfoot LeftFoot
ltoes LeftToeBase
rhipjoint RHipJoint
rfemur RightUpLeg
rtibia RightLeg
rfoot RightFoot
rtoes RightToeBase
# We can't translate "lowerback" to Spine because lowerback is in
# the same location as Hips. The MB docs say that you shouldn't do
# that.
lowerback LowerBack # child of hips
upperback Spine
thorax Spine1
# "Lower" and "upper" neck? Good grief.
lowerneck Neck
upperneck Neck1
head Head
lclavicle LeftShoulder # child of
thorax
lhumerus LeftArm
lradius LeftForeArm
lwrist LeftHand
lhand LeftFingerBase
# LFingers and LThumb aren't names used by MB. CMU notes that there's
# no data on these joints, so we want to ignore them.
lfingers LFingers
lthumb LThumb # child of lwrist
rclavicle RightShoulder # child of thorax
rhumerus RightArm
rradius RightForeArm
rwrist RightHand
rhand RightFingerBase
rfingers RFingers
rthumb RThumb # child of rwrist
# END OF CMU JOINT RENAMING TEMPLATE with comments
-----------------------------------------------------------------
FUTURE PROJECT IDEAS:
- Write a tutorial that shows MotionBuilder workflow for how to use a
BVH file.
- Make a Poser-friendly / DAZ-friendly release of this dataset. Doing
so will almost certainly require first retargeting the data, to
correct joint rotation problems.
- Make an .fbx release of this dataset, such that each .fbx file can
be imported directly into the MotionBuilder Story window as a
"motion clip".
- Clean/smooth the data?
- Any possibility of making this data SecondLife-friendly, or
importing it into MovieStorm?
CHALLENGE TO PROGRAMMERS:
The hobbyist and animation prosumer world needs a lower-cost
alternative to Autodesk Motionbuilder, which at $3500 MSRP is out of
reach of the hobbyist animator. Today for $50 I can buy a wide
variety of consumer software packages that let me import, edit,
refine, and transition a series of home video clips, but if I want to
import, edit, refine, and transition a series of keyframes on the
joints of an animated character, I have to pay $3500. The first
software company or individual to produce a skeleton animation editor
which is BVH-friendly, DAZ-friendly, Poser-Friendly, and
SecondLife-friendly, with clean animation imports, exports, and
cross-rig animation retargeting for under $250, will make a mint.
CONTACT INFO AND WHERE TO FIND STUFF:
This BVH conversion release: www.cgspeed.com
Original CMU catabase (no BVH): mocap.cs.cmu.edu
AMC2BVH freeware utility: http://vipbase.net/amc2bvh/
MotionBuilder: www.autodesk.com/motionbuilder
To contact the creator of this BVH conversion release: hahne at io dot com
If you like this BVH conversion release, feel free to drop me email
and let me know what you're doing with it. If it turns out that
nobody needs a BVH dataset like this, then there's probably no point
in me doing public releases of other improvements.