Bug #515

Exporters are of Variable Fidelity in moving assets

Added by Rob Baer over 4 years ago. Updated almost 2 years ago.

Status:NewStart date:09/03/2014
Priority:NormalDue date:
Assignee:Jonas Hauquier% Done:


Target version:MakeHuman 1.1.2


r1282 on Windows 7

I systematically evaluated 5 of our exporters that can potentially be used to move MakeHuman model assets from MakeHuman to Blender. The five export formats were .dae, .fbx, .mhx, .obj, and .stl. A single, clothed model with hair, eyelashes, and eyebrows was exported with default export settings (feet-on-ground and decimeter). For Collada (.dae), y up face z was used. For steriolithography (.stl), ASCII was used. The exported .fbx file was converted to binary using the Autodesk FBX Converter x64 2013 to produce a binary .fbx format readable by Blender.

All files were imported into Blender 2.71 using the standard plugins. The files were imported with the Blender render setting set to Blender Internal. For Collada (.dae), the file was imported with "import units" in the T-panel both checked and unchecked. As the result did not seem to differ, only one .dae import is shown. Two anomolies (unique import results) should be reported: 1) The Autodesk FBX file was one thenth the size of the other imports despite having decimeter set on export. [To make comparison easier, this file was sized up (5x) before rendering]; and 2) The stereolithogrpah (.stl) file was imported on its back and was rotated 90 degrees about x to make its display in line with others.


Only the .mhx format produced good rendering of the face following simple import of the figure. Specifically, .dae, .fbx, and .obj formats resulted in improper rendering of eyes, eyebrows, and eyelashes. This seems related to the handling of transparency? The .stl format produced a model with no rendered material (but I'm not sure it even supports materials). Interestingly, clothes materials including textures rendered well in all exported formats with the exception of .stl. Perhaps this is because there is no need to deal with an alpha channel or perhaps its better implemented export code. This should be investigated.

Conclusions (TODOs)
  • Figure out how to improve export of eye, eyelash, eyebrow (and perhaps tongue and teeth?) materials for .dae, .obj, and .fbx
  • Add a y up face z option for .stl (along with the other choice currently available in .dae), and if supported materials
  • Investigate the different handling of scaling for the .fbx format and the other formats and try to make the scaling consistent across all export formats

screenshot_1_1409771771_ExportSet.png (446 KB) Rob Baer, 09/03/2014 09:16 PM


Related issues

Related to MakeHuman - Bug #586: collada posed-export to Blender Fixed 10/17/2014
Related to MakeHuman - Bug #1009: Feet on the ground Rejected 04/03/2016
Related to MakeHuman - Bug #1148: Test/fix collada pipeline vs various external platforms New 03/12/2017


#1 Updated by Rob Baer over 4 years ago

One other minor improvement to the .dae and .fbx exporters would be to provide a "nicer" name for the exported object. Right now the base object for .dae is python and the .fbx exporter produces a series of objects named python and pythonmesh.

#2 Updated by Anonymous over 4 years ago

Thank you Rob, as usual you have done a very good work.
Now it's matter to find a resource available to work on this.

The steps to do are:

1) Modify manually, in a text editor, the exported files (priority: dae) in order to obtain a perfect character in Blender.
2) Compare the original exported file with the modified one, in order to understand the difference in material definitions.
3) Implement the changes to the exporters.

#3 Updated by Jonas Hauquier over 4 years ago

Note that evaluating equality between these formats is very subjective and in this case has been done only using the Blender importers for these formats (which arguably are not all that standardized). Evaluation also has been done only comparing to Blender standards.

Scale is something very subjective, and most formats do not include specific conversions to formal units (I believe DAE does). What scale is eventually imported in Blender probably depends on some random scaling factor that the programmer that wrote the importer plugin figured worked well. There's a good choice this scaling factor was decided based on the sample meshes they happened to have on hand for testing the importer. If there is no formal notion of scale in the format, the only thing you can do is hack it to play well with Blender's importer, but there is a good chance that it will result in complete ranomness when importing in a different tool than blender.

STL does not have material support, so that's not an issue.

As far as I can see, most material issues are due to transparency. This is an ever-old issue, that I do not think is a fix for. I seem to remember that FBX and DAE materials explicitly exclude the correct transparency setting, if Blender importers chose not to act upon this, then that is it.

What we can do is, as Manuel suggested, verify the specification of those formats, and verify that the MH exports are effectively doing all they can to communicate transparency. If this is the case, we could file a bug report on the Blender tracker for the affected importer, asking them to obey property X and make it import transparency.

In any case, transparency is not only an issue in Blender, it's a problem for Unity as well, and perhaps other tools.

An important remark is that we should focus mainly on one export format per tool, and explicitly write this in the documentation. For example for Blender we could recommend Collada (or mhx variant if they want mhx features). It's not needed to achieve perfect Blender compatibility for all the available formats, if one format is enough to get your mesh exported.

#4 Updated by Jonas Hauquier over 4 years ago

It would be great to devise a list of tools and the recommended formats for exporting to them. Then evaluate the compatibility for those tools.

#5 Updated by Jonas Hauquier over 4 years ago

Sadly, fixing scale for FBX appears to be a hopeless case. The format appears to have no real means of specifiying what the scale is, compared to say a meter scale.
It's so bad that if you export a mesh from MAX to Maya using FBX (both Autodesk software!) the scale is x10 and you need to manually correct it.

Note that most of the times the FBX importer has a scale option (Blender FBX import might have one too) that you can use to compensate for this difference.

Apparently Maya always uses cm units by default, but can be changed upon import.

#6 Updated by Rob Baer over 4 years ago

  • Related to Bug #586: collada posed-export to Blender added

#8 Updated by Rob Baer almost 3 years ago

  • Related to Bug #1009: Feet on the ground added

#9 Updated by Aranuvir # almost 2 years ago

  • Target version set to MakeHuman 1.1.2

#10 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #1148: Test/fix collada pipeline vs various external platforms added

Also available in: Atom