Bug #967

FBX Export to Blender

Added by Rob Baer over 3 years ago. Updated 10 months ago.

Status:Fix exists, needs testingStart date:10/18/2015
Priority:NormalDue date:
Assignee:Thomas Larsson% Done:

0%

Category:FBX
Target version:MakeHuman 1.1.2

Description

r1963 windows 10 Blender 2.76

Steps:
1. Export 4 models as binary fbx using default bone and mesh axis orientations, each to a separate file with cm, dm, in, and meter units
2. Import to Blender with default fbx importer
3. View from RIGHT ortho view.
--------------------
Note that bone translations/offsets seem corrupted
Note that default pairings are not Friendly to MH --> Blender workflows
Note that the names for the imports are taken from an unchanging ,generic skeleton name, and not from the file name of the MH export as used to be the case

--------------------------

screenshot_1_1445190893.png (76 KB) Rob Baer, 10/18/2015 07:55 PM

fbx-right.png (46.7 KB) Thomas Larsson, 10/19/2015 08:06 AM

screenshot_1_1445274379.png (190 KB) Rob Baer, 10/19/2015 07:07 PM

screenshot_2_1445274451.png (26.8 KB) Rob Baer, 10/19/2015 07:08 PM

fbx-viewer.png (61.6 KB) Thomas Larsson, 10/20/2015 12:37 PM

fbx-import.png (23.7 KB) Thomas Larsson, 10/20/2015 12:37 PM

screenshot_4_1448186819.png (93 KB) Rob Baer, 11/22/2015 11:08 AM

screenshot_1_1455617413.png (66.9 KB) Rob Baer, 02/16/2016 11:13 AM

screenshot_1_1456022086.png (117 KB) Rob Baer, 02/21/2016 03:34 AM

1143
1145
1146
1147
1148
1149
1157
1184
1186

Related issues

Related to MakeHuman - Bug #951: Multiple problems with MakeHuman .bvh export to blender In Progress 08/24/2015
Related to MakeHuman - Bug #892: FBX Export Testing New 06/01/2015
Related to MakeHuman - Bug #955: Shadowing in Filmbox export New 09/14/2015
Related to MakeHuman - Bug #923: FBX scale handling behavior in 3DSMax, Maya, and Blender New 06/27/2015
Related to MakeHuman - Bug #958: Skeleton-handling and Scaling struggle with FBX Export & ... Rejected 09/26/2015

History

#1 Updated by Rob Baer over 3 years ago

  • Related to Bug #951: Multiple problems with MakeHuman .bvh export to blender added

#2 Updated by Rob Baer over 3 years ago

  • Related to Bug #892: FBX Export Testing added

#3 Updated by Rob Baer over 3 years ago

  • Related to Bug #955: Shadowing in Filmbox export added

#4 Updated by Rob Baer over 3 years ago

  • Related to Bug #923: FBX scale handling behavior in 3DSMax, Maya, and Blender added

#5 Updated by Thomas Larsson about 3 years ago

It does not look quite the same here. The character is standing on his feet, and the face bones are located at the face. Perhaps there is some import option in Blender that is set differently.

The face bones are far too big, but this is an issue with the fbx format. Like most 3D apps, fbx only stores the head joint and its transformation matrix - Blender does the same thing internally. This means that there is no info about the bone lengths. This is not a big problem for bones with children, because the bone's tail can be assumed to lie at the child's head (or the average of the children's heads). For a terminal bone there is no child, and the fbx importer has to make a guess about the bone length. This guess evidently goes wrong for the terminal face bones.

Blender's fbx exporter has an workaround for this: it adds an extra bone after each terminal bone. These extra bones can probably be eliminated if you check the Ignore Leaf Bones option. This is quite ugly, but I could add such an option to the MH exporter. Will think about it.

#6 Updated by Rob Baer about 3 years ago

Here is perhaps a more useful test set. Windows 10, Blender 2.76, MH R1963. Notice that the rotation on the mesh alone is xrot = 90, but that the mesh xrot rotation is zero when paired with a skeleton, but the sekleton xrot is 90. [EDIT: Note, the figure is mislabeled for default no-toes which has the same skeleton and mesh rotations as the other sets] The sekeleton remains standing in front view, but the mesh is laying down. The scale for all exports was "decimeter".

All were done with Blenders "default" FBX import settings

#7 Updated by Thomas Larsson about 3 years ago

I'm still on Blender 2.75, so maybe that's what makes the difference. The rig has xrot = 90 and the mesh has xrot = 0, but the mesh is standing up in my Blender. Perhaps there is a bug in Blender 2.76. The character looks fine in FBX converter 2013, which is more relevant than Blender since it uses the FBX SDK.

A snapshot of the FBX importer's options in Blender 2.75 is included. Compared to the one you showed, the Ignore Leaf Bones options seems to be gone. So it is a good thing I didn't got around to add extra leaf bones in the MH exporter.

#8 Updated by Thomas Larsson about 3 years ago

I have now downloaded Blender 2.76 and I can confirm that the character is lying on his back for me as well. Hence this seems to be a Blender bug.

#9 Updated by Rob Baer about 3 years ago

I have placed this issue on the Blender bug tracker and cross-referenced this discussion there.

https://developer.blender.org/T46581

#10 Updated by Rob Baer about 3 years ago

  • Related to Bug #958: Skeleton-handling and Scaling struggle with FBX Export & Blender Import added

#11 Updated by jujube (Forum User) about 3 years ago

It may still be related to the makehuman rig somehow - I had a similar bug when importing models into the marvelous designer demo, but only with rigged models. (I'm pretty sure it was obj format though)

#12 Updated by Rob Baer about 3 years ago

A little additional insight here. If one goes into edit mode in Blender, the bones and mesh rotate -90 on x and the figure stands upright. Returning to object mode makes it lay back down. Even in edit mode the face bones display as a huge mass at the human's feet.

Is there a rationale for why we don't apply rotation before export? Are we treating the mesh and skeleton the same in this regard?

#13 Updated by Thomas Larsson about 3 years ago

Like most 3d software, MH uses the Y up convention; the only exceptions that I know of are Blender and 3dsmax, which use Z up. So MH does not do any rotation at all; everything in the FBX file has Y up. The Blender importer has to compensate for Blender's nonstandard convention, and evidently it does so by doing an object rotation. Since object transformations are ignored in edit mode, the character ends up lying on his back.

Anyway, if Blender 2.75 and 2.76 treat the same fbx file differently, one of them must be wrong.

#14 Updated by Rob Baer about 3 years ago

Ahhhh... so the rotation appears because of the Blender importer not the MH exporter. That's helpful.

Anyway, if Blender 2.75 and 2.76 treat the same fbx file differently, one of them must be wrong.

That seems a reasonable deduction. Ignoring the Blender difficulties for a moment, is there any relationship between the unusual order we use for .bvh file columns (see http://bugtracker.makehumancommunity.org/issues/951#note-5) and the fact that BOTH the mesh and the rig don't sit on their back in Blender 2.76, or is the MH .bvh syntax irrelevant here?

I'm not even sure whether the MH exporter is pulling skeleton data and winding orders from a .bvh or a .json file when exporting coordinates?? Where is this handled in the code? Jujube (#11) suggests there may be some additonal issues beyond FBX mixed into this issue.

#15 Updated by Jonas Hauquier about 3 years ago

FBX contains metadata which specifies the up axis used in the file, and MakeHuman properly fills this information.
Probably, the blender importer verifies this information and rotates the objects when they are not stored with Z up, right-handed axis.
Upon export in MakeHuman, you can choose for a Z-up coordinate system, however. I believe if you select that, Blender will no longer rotate the objects.

#16 Updated by Rob Baer about 3 years ago

Jonas Hauquier wrote:

Upon export in MakeHuman, you can choose for a Z-up coordinate system, however. I believe if you select that, Blender will no longer rotate the objects.

Actually, it seems that the ability to choose an axis orientation is no longer available for any of the exporters except the collada (dae) exporter.

#17 Updated by Thomas Larsson about 3 years ago

Actually, I don't think it was ever implemented for anything but Collada. There was a need for this feature to export to Second Life, IIRC.

#18 Updated by Rob Baer about 3 years ago

  • Status changed from New to Fix exists, needs testing

Bastien Montagne (mont29) closed this task as "Resolved" [on the Blender side] by committing rBAdaf500661e0f: Fix T46581: Import FBX: Blender 2,.76 version breaks mesh rotation on FBX….

Apparently this problem was related [in ways I don't quite understand] to "Maya style" but not "3DSMax style" FBX.

Blender reference:
https://developer.blender.org/T46581

For reference, this fix was not included as of Blender 2.76b. Presumably, it will appear in a subsequent release.

#19 Updated by Rob Baer about 3 years ago

Tested import in Blender nightly 11-22-2015 build

Summary

1. Bastien's Blender fix means that the MH character once again aligns with skeleton and stands upright in object mode. However,the mesh does a face-plant in edit mode. Why are the skeleton and mesh orientations different? Is it an export specification issue?

2. The face bones without termination continue to be an issue, but the ignore leaf bone option is gone. Finger bones are terminal. Why do the finger bones display properly but not the face bones?

#20 Updated by Rob Baer about 3 years ago

This post during the Blender patch process may give us additional insight on our end:
https://developer.blender.org/rBAd7fa659c6f9d4922bbcf63d15a120786e1f6ee68

Fix T45834: FBX Importer failed to importer.

This file actually showed several issues:
*Not always using safe 'get_bind_matrix'
*Not protecting against zero-length bones in the force-connect area

#21 Updated by Jonas Hauquier about 3 years ago

Now I remember: the API supports changing the axis system but the gui does not offer it.

#22 Updated by Rob Baer almost 3 years ago

Given the fact that a lot of this issue (if not all of this issue) is Blender import problems, it seemed critical to look at an alternative FBX workflow. I chose Maya 2016 with the thought that the "Autodesk viewer" might be too smart and forgiving.

The skeleton and mesh seem upright and aligned when either binary or ascii FBX files made in MH r1999 are imported into Maya.

Perhaps we should suspend chasing this issue until Blender improves FBX import support. Having smooth FBX workflow into Blender is a laudable goal, but it should not hold back the release of MH 1.1.0. Moving target for this issue to MH 1.1.1 by which time Blender should be at release 2.77 and we can retest.

#23 Updated by Rob Baer almost 3 years ago

  • Target version set to MakeHuman 1.1.1

#24 Updated by Rob Baer almost 3 years ago

More MH FBX Export Blender import testing (moved from #958)

There is still some strangeness here. As the MH model is currently represented in the FBX file, it is interpreted by blender as having a modifier applied by Blender's importer. I could be wrong but this seems related to the fact that x-axis rotation does not get "applied".

At any rate deleting the modifier rotates the main mesh into the same direction as the bones, but hair, eyes, etc stay 90 degrees rotated in x in Blender object mode. Note that the pose seems intact. The other proxy meshes follow the (modifier deleted) main mesh orientation in edit mode. Here are Blender object mode images to illustrate the issue. What are we doing differently for exporting the clothes and other proxies than for exporting the main mesh? Is it possible to apply rotations on all assets at export time to fix this?

The difference between proxy and main mesh behavior point directly at the problem being MH exporter-related at least in part, and not totally on the Blender Importer side. If skeleton, main mesh, and proxies all came into Blender flat on their back, and unaffected by object mode/edit mode changes, we still would have improved the current state of things.

EDIT: Or is the pose skeleton in need of some transformation prior to export?

#25 Updated by Rob Baer almost 3 years ago

makehuman 1.1.0 (Hg r2008 stable) Win 10

There are several issues with Blender FBX importer just now which makes it more difficult to test our exporter against Blender. On the other hand if we don't push the Blender Devs things won't ever work. I've been struggling with getting consistent scale MH --> via FBX --> Blender.

Since it can matter, this test was done with a CMU skeleton character, not a mesh-only character.

Here is the thru-put for MH exporters at meter scale on export into Blender 2.75 with default importer settings

The results are somewhat different with Blender 2.76b in that the FBX mesh is the same size as the others but lies on its back. However, 2.76b had skeletal issues which we bugged and 2.77 DevtestBuild2 looks virtually the same as 2.75 did. At the movement there are still skeletal issues in 2.77. Don't know if they are MH related or Blender related.

In pose and edit mode the mesh lies at 90 degrees to the skeleton (FBX workflow only).

#27 Updated by Joel Palmius about 2 years ago

  • Target version changed from MakeHuman 1.1.1 to MakeHuman 1.1.2

#28 Updated by Rob Baer 10 months ago

The FBX export/import issue seems to persist as of Blender 2.79. See forum http://www.makehumancommunity.org/forum/viewtopic.php?f=6&t=15844&p=44077#p44041

I suppose one possible work-around would be to transform the model to a z-up orientation during export. The possible downside would be that it breaks import into programs like Maya. However those programs presumably are built on the Autodesk SDK and theoretically should be able to handle any export that is done to specification.

#29 Updated by Rob Baer 10 months ago

I peeked at our code, and I'm not convinced we are handling this right. There seems room to use the transformation routines in the collada plugin to more generally support the same variety of axis orientations we do with that plugin.

Also available in: Atom