BVH Hip Translate Moving 2.5 times More Than Expected

[Cathy Foil]

Perhaps someone can help me with this.  I am working on adding a new feature to my MayaStar plug-in.
I am adding the ability to make animations with it.

I got just about everything working except when I animate the avatar moving in any of the XYZ axis when I upload the animation and play it in SL the avatar actually moves about 2.5 times farther than the BVH code would indicate it should.

If the animation moves the avatar 100 Centimeters in Maya it should move the avatar in SL the same amount 1 meter.
When I measure it in SL though the avatar actually moves about 2.5 meters.

I have carefully examined the BVH file and indeed according to the numbers show a change of 100 unites which I assume are centimeters.  I have even edited the BVH file manually to make sure the avatar starts on Zero and ends on 100.

I could just make my avatar in Maya bigger to compensate so it is in proportion but I would really like to know exactly how far does the hip or mpelvis moves in SL then according to the BHV file it moves a 100 unites.

UPDATE: OK I played around with the scale of the avatar in Maya and think I got it to work pretty accurately.  See the default avatar was originally created by LL using Maya but when they created it they messed up and created the avatar tiny.  I can only assume that they thought they were working in meters when in fact the default unites in Maya is centimeters.  At first when I animate the tiny avatar in Maya the rotations were fine but when I try to make the avatar move then uploaded the BVH file the animation in SL would barely make the avatar move.  So I scaled up the avatar 100 times making it the real size it is in SL and tried animating it.  Again the avatar rotations were fine but the translations, meaning when the mpelvis would move it would move 2.5 times farther than it should as I already explained.  Anyway I calculated that 1 meter was 40% of 2.5 meters.  So instead of scaling my avatar up 100 times I scaled it up to just 40.  Now the avatar seems to be the correct size for animating in Maya.  I still like to know the exact amount a 100 unites of movement in the BVH file will make that avatar move in SL so I could get the exact scale for the avatar.

[Aquila Kytori]

Hi

Just me thinking out loud ........

---

Cathy Foil wrote:

............

If the animation moves the avatar 100 Centimeters in Maya it should move the avatar in SL the same amount 1 meter.

When I measure it in SL though the avatar actually moves about 2.5 meters.

I have carefully examined the BVH file and indeed according to the numbers show a change of 100 unites which I assume are centimeters.  I have even edited the BVH file manually to make sure the avatar starts on Zero and ends on 100.

I could just make my avatar in Maya bigger to compensate so it is in proportion but I would really like to know exactly how far does the hip or mpelvis moves in SL then according to the BHV file it moves a 100 unites.

UPDATE: OK I played around with the scale of the avatar in Maya and think I got it to work pretty accurately.  See the default avatar was originally created by LL using Maya but when they created it they messed up and created the avatar tiny.  I can only assume that they thought they were working in meters when in fact the default unites in Maya is centimeters.

 

---

Is it a coincidence that 1 inch = 2.54cm so 100 inches would be 2.54 meters.

Could they have made two mistakes , originally in scale and later mistaking inches for centimeters?

 

[Cathy Foil]

Awesome thinking Aquila!

I believe you are aboslutely right! 

To test your hypothesis I created a simple animation where the avatar moved straight up 100 centimeters in Maya and exported the BVH file.  Checked it in a world processor just to make sure that the BVH file did move exactly 100 units.

Then I created a simple small mesh of two cones where the point tips met each other exactly basically forming an hourglass.
Where the two pointy tips meet or the middle of the hourglass marks the eact center of the mesh.

I then snapped it to the mPelvis bone and rigged it to the skeleton and weighted it 100% to the mPelvis bone.  Exported it out as a DAE and uploaded it to SL.  Then I wore the mesh and made my avatar invisible.

Next I played a T-Pose animation to my avatar wouldn't move and created a cube.  I moved the bottom of the cube so it intersected with the middle of the hourglass mesh I was wearing on my mPelvis bone.  

I then played the animation that moved my avatar up exactly 100 unites and then stretched the top of the cube till it intersected the hourglass mesh new position.  The cube was now exactly 2.53985 tall.  So accounting for error since I had to scale up the cube by hand it was really 2.54 meters.

So it definitely looks like LL considers the unite of measurement of the BVH file to be in inches and then converts them to centimeters.

OK just to make sure I did the same thing in SL to measure the distance between mPelvis and another hourglass mesh I put at the center of the grid in Maya and weighted it to the mPelvis bone as well.  Wore it in SL and measured the distance between them to get the height of what the mPelvis should be in Maya. Then made another animation moving the avatar up to where the eye height is in Maya and then measured in SL again using the new animation.  Everything worked!

For those who like to know I scaled up the avatar in Maya from the tiny default skeleton 39.331947 times in XYZ scales to get the avatar to be the correct height for creating animations using Maya's default unit setting of Centimeters.

Love to hear if you have anyone has any other insights.

Thanks again Aquila!
Cathy

[Beq Janus]

Necro-ing this thread because of a conversation I had today, which taught me something new, that I think is worth sharing for the future.

The BVH format is essentially unit-less. There is no "units" section to define what the unit of measurement is, the best I can find is a comment that the units are "world units" which is equally meaningless without context. Perhaps the best summary of this is in the much-cited work by Meredith and Maddock, titled "Motion Capture File Formats explained".

Quote

There are a number of problems inherent in the BVH file format. Most noticeable is the fact that there is no explicit bone orientation. Although the bone lengths can be inferred from child bones, the problem comes with multiple children, as previously discussed – which child do you use to infer the parent’s bone length? Furthermore, it is also desirable to have the bone along a single axis and a rotation matrix to orientate it into its base position for reasons that will be discussed later. Other problems with the BVH files include the lack of calibration units, such as the scale that the joint offsets are measured in, and details about the environment, such as orientation – i.e. which direction points upwards? 

However, as @Aquila Kytori and @Cathy Foil observed here there is an implicit use of inches when importing from BVH, the reasons for this are lost in time. Perhaps @Vir Linden may have some insight into the history of this?

There is a useful nugget "hidden in plain sight" as is often the case http://wiki.secondlife.com/wiki/BVH_Hip_Location_Limits. 

My guess is that whatever sample animations the original importer was tested with, they were using inches and that somehow became a de facto standard. 

Note however that the inches unit is only relevant when reading BVH, the Second Life internal animation format (.anim) is "effectively" metric using an unsigned 16-bit integer to represent 0-5m in 1/65535 increments. The .anim format is documented here http://wiki.secondlife.com/wiki/Internal_Animation_Format

This little gotcha is quite well hidden, as far as I can tell it appears just once in the viewer code, during the conversion of imported BVH data to a KeyFrameMotion object (which is the data that we, as users, then add things such as priority, ease_in and ease_out etc

The BVH format itself has not units, as I said above, however, I did manage to uncover the original specification and it had this "enlightening" statement.

Quote

Establishing a Correct Neutral Pose

In creating a BVH file that can be read into Character Studio Biped and displayed correctly, it is critical that the effective neutral pose of the BVH match Biped's neutral pose. That is, the hierarchy, bone lengths, and initial rotations specified in the HIERARCCHY section of the BVH file must create a figure that matches the default pose of a newly-created Biped figure. The initial pose for Biped places the biped figure upright along the +Z axis, facing "forward" along the -Y axis, left hand on the +X axis. Hands are oriented with palms against the outside thighs, with thumb on the forward side; fingers and thumb of each hand outstretched (open) facing "down" along the -Z axis. Legs are together and straight at the knees.

A correctly oriented BVH file can be verified by setting all rotational values in the first frame of the MOTION section to zeroes. When all joint rotation values are set to zero for the first frame of the BVH file, the results displayed at frame zero in Biped, after import, should match the default position of the Biped exactly.

3

Which goes a long way to explaining why we ever ended up with the illogical -Y forward orientation for animations. This stated, "neutral pose" also explains the lack of orientation encoded in the BVH itself.

Hopefully, this little tidbit of info sitting here on the forums will make it slightly more likely that a person seeking this knowledge in future will find it. Thanks to @LichtorWright for pointing me at the Hip locations info in the first place.