BVH Exporter mishandles non-origin root bone #44690

New Issue

Rob Baer · 2015-05-13T04:23:11+02:00

Rob Baer commented

2015-05-13 04:23:11 +02:00

BVHProblem.zip
Blender seems to improperly EXPORT BVH. Attached is .zip a round trip import-export pair of files that demonstrate that Blender does not return the same file it imports.

The image shows the improper consequence of import/export round trip in Blender.

Blender Exporter seems to treat frames as absolute positions not as relative to the root. It improperly displaces the root {These references all agree that the position frame channels are translations, and not absolute positions:
http://www.dcs.shef.ac.uk/intranet/research/public/resmes/CS0111.pdf
Refer to equation 3.2 on page 8 and the description next to it.
"Therefore,Tx,Ty and Tz represent the summation of abone’s base position and frame translation data."

http://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html
"The rot filesation data comes from the motion section. For the root object, the translation data will be the sum of the offset data and the translation data from the motion section"

OS Name Microsoft Windows 8.1 Pro
Version 6.3.9600 Build 9600
Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz, 2394 Mhz, 4 Core(s), 8 Logical Processor(s)
Adapter Type GeForce GTX 780M, NVIDIA compatible
Adapter Description NVIDIA GeForce GTX 780M
Adapter RAM (1,048,576) bytes
Installed Drivers nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um
Driver Version 9.18.13.5012

[BVHProblem.zip](https://archive.blender.org/developer/F173723/BVHProblem.zip) Blender seems to improperly EXPORT BVH. Attached is .zip a round trip import-export pair of files that demonstrate that Blender does not return the same file it imports. The image shows the improper consequence of import/export round trip in Blender. Blender Exporter seems to treat frames as absolute positions not as relative to the root. It improperly displaces the root {These references all agree that the position frame channels are translations, and not absolute positions: http://www.dcs.shef.ac.uk/intranet/research/public/resmes/CS0111.pdf Refer to equation 3.2 on page 8 and the description next to it. "Therefore,Tx,Ty and Tz represent the summation of abone’s base position and frame translation data." http://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html "The rot filesation data comes from the motion section. For the root object, the translation data will be the sum of the offset data and the translation data from the motion section" OS Name Microsoft Windows 8.1 Pro Version 6.3.9600 Build 9600 Processor Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz, 2394 Mhz, 4 Core(s), 8 Logical Processor(s) Adapter Type GeForce GTX 780M, NVIDIA compatible Adapter Description NVIDIA GeForce GTX 780M Adapter RAM (1,048,576) bytes Installed Drivers nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um Driver Version 9.18.13.5012

Rob Baer commented

2015-05-13 04:23:12 +02:00

Changed status to: 'Open'

Rob Baer commented

2015-05-13 04:23:12 +02:00

Added subscriber: @RobertBaer

Campbell Barton was assigned by Bastien Montagne

2015-05-13 15:13:37 +02:00

Bastien Montagne commented

2015-05-13 15:13:37 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2015-05-13 15:13:37 +02:00

Code seems to be doing what's expected here...(re movement and all).

However, it seems to apply some kind of global rotation of armature somehow…

Code seems to be doing what's expected here...(re movement and all). However, it seems to apply some kind of global rotation of armature somehow…

Jonas H commented

2015-05-13 16:25:55 +02:00

Added subscriber: @duststorm

Jonas H commented

2015-05-13 16:25:55 +02:00

The example file does not seem to illustrate this issue. What happens in the example file is that it rotates the entire skeleton to convert from Z up to Y up coordinates (or the other way around).

The issue I was seeing, is that BVH export copied the offset of the root joint in the X/Y/Zposition channels of the MOTION, even if the animation track in blender had no translation on that bone, only rotations.
Now, I have only tried this with Blender 2.72b so I'm not sure whether this is fixed in the meantime (which is why I outsourced investigation of this issue), but my observations are described here:
http://bugtracker.makehuman.org/issues/758#note-6

Recreating this bug should be fairly straightforward:
Create a new armature in Blender, add one bone, place this bone's head at a different position than the origin. Apply a pose to this armature containing only rotations, no translations. Export to BVH.
When observing the BVH file, the root joint will contain translation channels, and they will be non-zero. In fact they will contain the same coordinates as the offset of the root joint. This is contradictory to the literature pointed to by Rob. It also seems to contradict a variety of existing BVH implementations, for example BVHacker.

The example file does not seem to illustrate this issue. What happens in the example file is that it rotates the entire skeleton to convert from Z up to Y up coordinates (or the other way around). The issue I was seeing, is that BVH export copied the offset of the root joint in the X/Y/Zposition channels of the MOTION, even if the animation track in blender had no translation on that bone, only rotations. Now, I have only tried this with Blender 2.72b so I'm not sure whether this is fixed in the meantime (which is why I outsourced investigation of this issue), but my observations are described here: http://bugtracker.makehuman.org/issues/758#note-6 Recreating this bug should be fairly straightforward: Create a new armature in Blender, add one bone, place this bone's head at a different position than the origin. Apply a pose to this armature containing only rotations, no translations. Export to BVH. When observing the BVH file, the root joint will contain translation channels, and they will be non-zero. In fact they will contain the same coordinates as the offset of the root joint. This is contradictory to the literature pointed to by Rob. It also seems to contradict a variety of existing BVH implementations, for example BVHacker.

Rob Baer commented

2015-05-13 17:17:18 +02:00

Perhaps this image will further clarify the issue.

![BVHIssue.png](https://archive.blender.org/developer/F174058/BVHIssue.png) Perhaps this image will further clarify the issue.

Jonas H commented

2015-05-22 01:25:12 +02:00

I'm attaching two simple blend files for testing the patch.
The first contains only one bone, this is an edge case (only one bone, the root bone)
bvhtestA.blend

The second has two bones
bvhtestB.blend

The root bone doesn't have it's head at the origin, its head is at Z=0.35, its tail at Z=1.35, thus length == 1
The child bone (in the second file) has its head at Z=1.35 and its tail at Z=2, X=0.5

The things to verify are:

The bones have no pose transformations, so the exported BVH file is expected to have all zeros in its animation channels
The joint offsets in the BVH file are correct (relative to parent)
Importing the BVH file again, the armature or object structure should be identical to the blend file (import with Z up, face Y)

I'm attaching two simple blend files for testing the patch. The first contains only one bone, this is an edge case (only one bone, the root bone) [bvhtestA.blend](https://archive.blender.org/developer/F178645/bvhtestA.blend) The second has two bones [bvhtestB.blend](https://archive.blender.org/developer/F178646/bvhtestB.blend) The root bone doesn't have it's head at the origin, its head is at Z=0.35, its tail at Z=1.35, thus length == 1 The child bone (in the second file) has its head at Z=1.35 and its tail at Z=2, X=0.5 The things to verify are: * The bones have no pose transformations, so the exported BVH file is expected to have all zeros in its animation channels * The joint offsets in the BVH file are correct (relative to parent) * Importing the BVH file again, the armature or object structure should be identical to the blend file (import with Z up, face Y)

Brendon Murphy commented

2016-03-05 05:14:43 +01:00

Added subscriber: @BrendonMurphy