Bug #951

Multiple problems with MakeHuman .bvh export to blender

Added by Rob Baer over 3 years ago. Updated about 2 years ago.

Status:In ProgressStart date:08/24/2015
Priority:HighDue date:
Assignee:Jonas Hauquier% Done:


Category:File export
Target version:MakeHuman 1.1.2


Windows 7 r1959

Steps to reproduce:

Start MH and select default skeleton and T pose
Click Export and check .bvh
Import into Blender 2.75a

The exported file is called Eport01:

Note that the name that got exported has has had the pose appended to it automatically prior to export so that it was actually exported as Export01_tpose.bvh. During import, the Blender import settings are as follows:

The resulting skeleton looks as follows in Blender:

Note the lack of T-pose.

Even if this is a Blender import problem, there is an additional issue. If one selects several different poses prior to exporting, MakeHuman saves multiple .bvh files appended with each of the poses selected prior to export. For example, re-exporting Eport01 yields this after selecting each of the four 'fight poses' and two 'fly pose' (just in order nothing else) and then exporting using the same Eport01 name:

The different exported files contain different skeletal poses, but the distortion is bad enough that is difficult to tell if the poses correspond to the pose names or not.

screenshot_1_1440429142.png (89.3 KB) Rob Baer, 08/24/2015 05:12 PM

screenshot_2_1440429751.png (49.5 KB) Rob Baer, 08/24/2015 05:22 PM

screenshot_3_1440429943.png (60.9 KB) Rob Baer, 08/24/2015 05:26 PM

screenshot_4_1440430321.png (144 KB) Rob Baer, 08/24/2015 05:32 PM

screenshot_5_1440431057.png (116 KB) Rob Baer, 08/24/2015 05:44 PM

t-pose.jpg (53.7 KB) wolgade (Forum User), 08/26/2015 06:45 PM

benchmark.jpg (54.7 KB) wolgade (Forum User), 08/26/2015 06:45 PM

screenshot_1_1440739745.png (83.3 KB) Rob Baer, 08/28/2015 07:29 AM

screenshot_1_1440742626.png (111 KB) Rob Baer, 08/28/2015 08:17 AM

screenshot_1_1441376317.png (125 KB) Rob Baer, 09/04/2015 04:19 PM

fbx-export.png (75.2 KB) Thomas Larsson, 09/26/2015 05:18 PM

fbx-export.png (73.7 KB) Thomas Larsson, 09/26/2015 05:22 PM

screenshot_1_1443284582.png (87.8 KB) Rob Baer, 09/26/2015 06:23 PM

screenshot_2_1443284871.png (87.8 KB) Rob Baer, 09/26/2015 06:28 PM

screenshot_1_1443286297.png (23.7 KB) Rob Baer, 09/26/2015 06:52 PM


Related issues

Related to MakeHuman - Bug #967: FBX Export to Blender Fix exists, needs testing 10/18/2015
Related to MakeHuman - Feature #392: BVH exporter: add "feet on ground" and scale options In Progress 05/20/2014


#2 Updated by wolgade (Forum User) over 3 years ago

Are we sure this is just an export problem?

If you import the bvh files from makehuman/data/poses they look really weird in blender.

#3 Updated by Rob Baer over 3 years ago

Wolgade writes:

Are we sure this is just an export problem?

Yes. As per the heading there are multiple problems -- at least one of which is the export of multiple .bvh files after selecting multiple poses. There be some import issues with Blender which we can't rule out. And finally, the fundamental format of the saved pose .bvh may not satisfy assumptions of other programs.

I took a look at trying to load the files as stored in the Mercurial MakeHuman with bvhHacker. The program crashes trying to load the poses:

The program at first complains that "Mac line endings"may be the cause of the problem (Windows machine), but after making the line ending windows endings with WordPad the complaint remains the same. So, whatever is causing this issue is something else.
Why is it that poses make it from MakeHuman to Blender as .dae, .fbx, and .mhx2, but not as straight-forward .bvh?

Is there something about needing at least one frame of animation?

#4 Updated by Rob Baer over 3 years ago

Also tried BVHViewer from Development in Motion. MH poses appear quite small and lack form. For comparison I display an "Advanced Computing Center for Arts and Design" (ACCAD file, not AACAD <G>) with the same viewer:

#5 Updated by Rob Baer over 3 years ago

It seems that MH pose files are written with a different rotation order than used in most other places. Although this may not strictly ignore "spec", it could confuse importers/parsers that presume certain conventions.

MakeHuman pose file:

ROOT root {
OFFSET 0.000000 0.639400 0.631400
CHANNELS 6 Xposition Yposition Zposition Xrotation Yrotation Zrotation
JOINT pelvis.R {
OFFSET 0.000000 -0.790650 0.041951
CHANNELS 3 Xrotation Yrotation Zrotation
JOINT upperleg01.R {
OFFSET -1.026150 0.083862 -0.083200
CHANNELS 6 Xposition Yposition Zposition Xrotation Yrotation Zrotation
JOINT upperleg02.R {
OFFSET -0.106400 -0.106258 -0.786658
CHANNELS 6 Xposition Yposition Zposition Xrotation Yrotation Zrotation
JOINT lowerleg01.R {
OFFSET -0.307100 -0.219482 -3.204812

Example of the usual rotation order BVH file:

ROOT Hips {
OFFSET 0.00 0.00 0.00
CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
JOINT Chest {
OFFSET 0.00 5.21 0.00
CHANNELS 3 Zrotation Xrotation Yrotation
JOINT Neck {
OFFSET 0.00 18.65 0.00
CHANNELS 3 Zrotation Xrotation Yrotation
JOINT Head {
OFFSET 0.00 5.45 0.00
CHANNELS 3 Zrotation Xrotation Yrotation
End Site {
OFFSET 0.00 3.87 0.00

From http://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/BVH.html:
> "You can see that the order of the rotation channels appears a bit odd, it goes Z rotation, followed by the X rotation and finally the Y rotation. This is not a mistake, the BVH format uses a somewhat unusual rotation order. Place the data elements into your data structure in this order.

On the line of data following the channels specification there can be one of two keywords, either you will find the "JOINT" keyword or you will see the "End Site" keyword. A joint definition is identical to the root definition except for the number of channels. This is where the recursion takes place, the rest of the parsing of the joint information proceeds just like a root. The end site information ends the recursion and indicates that the current segment is an end effector (has no children). The end site definition provides one more bit of information, it gives the length of the preceding segment just like the offset of a child defines the length and direction of its parents segment".

Indeed, the "Zrotation Xrotation Yrotation" order is used by both CMU-BVH and ACCAD-BVH files.

#6 Updated by Rob Baer over 3 years ago

Just a little additional insight. The problem related to the exporter handling of .bvh files after viewing multiple poses stands.

The problem related to .bvh throughput from MH to Blender is likely not a STRICT export problem. It appears to be a problem related to exporting (perhaps within the standard) in a format that importers do not always interpret correctly (see comment 5 on order). If further support of this notion, I tried importing in yet another importer (Open Asset library viewer) and it DOES seem capable of reading in MH pose .bvh files correctly.

Here is how the fight01 pose looks when first importing in and after rotating it to see the bones and joints. Everything appears properly oriented despite Blender and BVHViewer struggling on this same file.

#7 Updated by Thomas Larsson over 3 years ago

How much of this is still a problem? I tested to import a T-posed character, in two ways:

1. MH FBX export -> Blender FBX import.
2. MH MHX2 export -> Blender MHX2 import -> Blender FBX export -> Blender FBX import.

The pose now seems correct, apart that the face bones are far too long. If we look closer at the rig exported from Blender, we notice that there are extra terminal bones - the new bone breast.L_end is highlighted. Is this the desired behaviour? Adding extra bones (or more correctly nodes) that are not needed for animation does not seem right.

#8 Updated by Thomas Larsson over 3 years ago

And here is the picture

#9 Updated by Thomas Larsson over 3 years ago

  • File fbx-export.png added
  • Status changed from New to Fix exists, needs testing

The fight01 pose seems to work too, so I think this is fixed.

#10 Updated by Rob Baer over 3 years ago

Windows 8.1 r1960

So this particular problem exists at the level of the BVH exporter (I think) and not necessarily at the level of the skeleton/pose (which I say with all due caution of my ignorance :). Note that this is the "BVH exporter" and not the "FBX exporter".

Steps to reproduce:
1. Select the default skeleton.
2. Add the T-pose (or for that matter the fight01 pose).
3. Bring up export tab, check under rig format the Biovision BVH format, and enter the name TPoseDefault in the export box.
4. Note that the rig is saved with the name: "TPoseDefault_fight01.bvh" because of a previous export. Some aspect of a skeleton choice is getting appended to the name (in ways that may be delayed to a previous export?)
(see comment 11)

5. Import the skeleton into Blender and note that the skeleton does not take on its expected shape. As per comments above this is not Blender-specific" but import into in several BVH-specific tools seems corrupted as well. In Blender the look of the T-pose and fight01 as examples:

Summary of the 2 problems:
1. The export name that the user supplies in the dialog is extended by the export code.
2. There appear to be X? axis symmetry problems with the skeleton as imported into other programs. I am imagining this is do to the unusual column order we use during the export. [Even though this order may be completely legitimate] see http://bugtracker.makehumancommunity.org/issues/951#note-5

For completeness, this is related to forum post:

#11 Updated by Rob Baer over 3 years ago

Everything after the underscore in the names was added by the BVH exporter rather than the user and seems to have more to do with previous poses than the current pose.

#12 Updated by Rob Baer over 3 years ago

  • Related to Bug #967: FBX Export to Blender added

#13 Updated by Rob Baer almost 3 years ago

  • Related to Feature #392: BVH exporter: add "feet on ground" and scale options added

#14 Updated by Joel Palmius over 2 years ago

  • Status changed from Fix exists, needs testing to In Progress
  • Target version changed from MakeHuman 1.1.0 to MakeHuman 1.1.1

Reading between the lines it seems this is not actually fixed.

But seeming as the issue has gained very little interest in the last half a year, I'm bumping it to 1.1.1.

#15 Updated by Rob Baer over 2 years ago

Some of this is cross-related with #351, and Jonas is looking at some of these issues in the context of that issue. Whether this can be closed depends to some extent on his perspective of the interrelationships of these issues at the file structure and code level.

#16 Updated by Joel Palmius about 2 years ago

  • Target version changed from MakeHuman 1.1.1 to MakeHuman 1.1.2

Also available in: Atom