This is the new READMEFIRST file distributed with the 2010 Motionbuilder-friendly release.
READMEFIRST v1.1, last update June 26, 2010 by B. Hahne
This READMEFIRST file accompanies the second (2010)
Motionbuilder-friendly 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.
I released the original Motionbuilder-friendly BVH conversion in 2008.
This 2010 release is very similar, but has a few minor adjustments to some
of the joint rotations of the frame-one T pose which are intended to
make retargeting look slightly better in most cases. This 2010
release doesn't touch any of the other frames and doesn't change the
Motionbuilder-friendly joint naming convention of the 2008 release.
In general, you'll probably want to use this 2010 release.
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 (2010)
maintain the web site www.cgspeed.com, where this BVH conversion
release is available within the motion capture section.
The emphasis on this release is to produce BVH files that can rapidly
be used in MotionBuilder for motion retargetting. The files are not
particularly Poser-friendly or DazStudio-friendly, due to
incorrect assumptions that those programs have to make about the
underlying joint rotation setup. A conversion for use with Daz
characters is in its early stages as of June 2010.
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.
COMPARISON OF THE 2008 AND 2010 MOTIONBUILDER-FRIENDLY RELEASES:
The original CMU BVH files don't provide T poses, which means it's
impossible to determine or recover the exact physical rotation of the
human actor's joints when the motions were recorded. The situation is
made worse by the fact that the data is recorded using many different
subjects, and was presumably captured over multiple days or weeks with
different people operating and calibrating the motion capture
equipment. The best that we can do is make a guess at a T pose, using
joint rotations that visually look like a T pose, but then adjusting
empirically so that we end up with retargeted animation that avoids
some of the most glaring flaws, such as elbows intersecting hips and
feet intersecting each other. This 2010 release modifies the original
T pose slightly, based on my experiments with retargeting the CMU BVH
data onto one of the Daz characters.
For both the 2008 and 2010 Motionbuilder-friendly releases, the T pose
that I've added is in frame 0. All other frames are from the original
CMU capture sessions.
- The 2008 release set the Z rotations of the upper arm joints
("RightArm" and "LeftArm" in MotionBuilder's naming convention) to 5
degrees and -5 degrees respectively, to reduce problems with
retargeted animation bending the arms down too much. In the 2010
release, I've changed these values to 8 and -8 degrees, which
increases the level of compensation slightly.
- The 2008 release set the Z rotations of the upper leg joints
("RightUpLeg" and "LeftUpLeg" in Motionbuilder's naming convention)
to 17 and -17 degrees respectively, to reduce problems with
retargeted animation bending the legs in towards each other too
much. In the 2010 release, I've changed these values to 21 and -21
degrees, which increases the compensation slightly.
- The 2008 release set all neck and head joint rotations to zero,
which looks good visually within Motionbuilder but typically results
in characters who have their neck bent far forward when you
retarget. The 2010 release uses non-zero X rotations on the neck
and head joints, in an effort to provide a T-pose for the head which
is probably closer to what the joint readings would have been when
the original motion capture actors looked straight ahead. The
values in the 2010 release, for the Motionbuilder joints, are:
Neck: X rotation = -16 degrees
Neck1: X rotation = 21 degrees
Head: X rotation = 11 degrees
The net result of this compensation is to rotate the head up by
about 15 degrees in retargeted animation, compared to use of the
2008 BVH release. However, for some of the BVH files you might find
that you need to tilt the head up even more than this.
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. This script is unreleased.
- 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 use 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
-----------------------------------------------------------------
CONTACT INFO AND WHERE TO FIND STUFF:
This BVH conversion release: www.cgspeed.com in the motion capture section
Original CMU database (not BVH): mocap.cs.cmu.edu
AMC2BVH freeware utility: http://vipbase.net/amc2bvh/
MotionBuilder: www.autodesk.com/motionbuilder
BVHacker free BVH editing software: http://davedub.co.uk/bvhacker
BVHacker is designed primarily to create BVH files for SecondLife.
To contact the creator of this BVH conversion release: hahne@io.com
If you like this BVH conversion release, feel free to drop me email
and let me know what you're doing with it.