Bug #878

Document and/or fix the process from MH to Blender (particularly cycles)

Added by Joel Palmius over 3 years ago. Updated almost 2 years ago.

Status:NewStart date:05/28/2015
Priority:LowDue date:
Assignee:Joel Palmius% Done:


Category:File export
Target version:MakeHuman 1.1.2


I'm knowingly marking this as a bug rather than a feature, since it currently really doesn't work all that well. I'm also knowingly putting it in the main makehuman project rather than in the documentation subproject, since I think there's a lot more to it than just taking a few explanatory screenshots.

Anyway, in 1.0.2 a user could basically do a one-click import in blender and expect to a have a fully rigged toon with all materials properly assigned (admittedly only in BI).

With 1.1.0 there is no such luck, unless I miss something (see below for my attempts). Working in cycles, at the very least you have quite a lot of work left to do every time you try to import something. And repeatedly setting up material nodes and assigning them every time you change and re-import something quickly gets somewhat old.

Since the first question any 1.0.2 + blender user is going to ask is how to do this, we should figure this out before releasing 1.1.0. This includes solving those things which doesn't work particularly well, or at least proposing workarounds.

First attempt, ASCII FBX

Cycles, ascii fbx

Second attempt, binary FBX

Cycles, binary fbx

Third attempt, collada. All materials got lost in the process.

Cycles, collada

Being frustrated, switching to blender internal to see if collada works with that at least

BI, collada

(looking closely at last image, you can see that hair and eyes are faulty, probably because of missing transparency)

For reference, this is an import (via the bundled MHX, not MHX2) from 1.0.2

Trying old 1.0.2 export

binary_fbx_import.png - Cycles, binary fbx (208 KB) Joel Palmius, 05/28/2015 10:07 AM

collada_to_blender_internal_render.png - BI, collada (148 KB) Joel Palmius, 05/28/2015 10:07 AM

vanilla_collada_import.png - Cycles, collada (169 KB) Joel Palmius, 05/28/2015 10:07 AM

ascii_fbx_import.png - Cycles, ascii fbx (139 KB) Joel Palmius, 05/28/2015 10:07 AM

1.0.2_to_blender_internal.png - Trying old 1.0.2 export (234 KB) Joel Palmius, 05/28/2015 10:20 AM


Related issues

Related to MakeHuman - Bug #546: Collada material properties incorrect for transparent obj... Accepted 10/06/2014
Related to MakeHuman - Bug #381: Exporters - Testing of new export configurations New 05/16/2014
Related to MakeHuman - Bug #468: Eyes not exported correctly to FBX Fixed 07/24/2014


#1 Updated by Anonymous over 3 years ago

The new way to handle this will be:

FBX, DAE --> Export only geometries + basic materials. How these materials are handled in Blender depends by the Blender importers.

Then we will provide two things:

1) An advanced rigging tool for Blender (with IK, expression sliders and so on). See issue #879 (yes this will delay the 1.1 a bit again)
2) A library of blender materials. The user will append and manually apply what he wants from a library with many alternative skins, eyes, etc.. Of course a basic knowledge of Blender will be required in order to be able to manually change the texture image.

#2 Updated by Jonas Hauquier over 3 years ago

Another good solution could be to have a very simple export format (eg. using something like collada and appending metadata for blender specific things) that export the mesh, the rigging and the materials in a no-nonsense way to blender, without all the cruft that more ambitious exporters add, conforming to the MH principles concerning output. And document this format.

But I generally think that what we need is someone that can devote some more time in debugging and testing the output formats and their compatibility in different software. This will probably solve a lot of the issues already.

We could also look for solutions in terms of different "dialects" of standard formats like DAE or FBX, to fit different tools. These could be selected as profiles, where the exporter no longer asks you what format you want, but what tool you want to export to.

#3 Updated by Rob Baer over 3 years ago

  • Related to Bug #546: Collada material properties incorrect for transparent objects added

#4 Updated by Rob Baer over 3 years ago

  • Related to Bug #381: Exporters - Testing of new export configurations added

#5 Updated by Rob Baer over 3 years ago

  • Related to Bug #468: Eyes not exported correctly to FBX added

#6 Updated by Rob Baer almost 3 years ago

In partial response to this, I have made a beginning contribution to the MH community wiki on workflows: http://www.makehumancommunity.org/wiki/MakeHuman_Workflows

Of course, I have also contributed many specific issues using DAE and FBX as vehicles for moving assets to other programs (mainly Blender) - see exporters list of #993. The results are not all bad, but we are not yet flawless. The question is what are our "quality targets" for the MH 1.1 release. If someone has comments on specifics, I'm more than willing to do the testing leg-work. We should refer to the exporter issues already open in making this decision (e.g., #993).

And there is a more than capable MHX2 for Blender-specific aspects that is a reasonable solution for MH 1.0.2 users of .MHX. This seems to port materials from MH to Blender Cycles quite nicely. Lets not set the bar so high that the MH 1.1 release never happens. We can continue our effort to fully support existing industry standards into the next release. Laudable goals should not become barriers.

Are there additional things, I could help with documentation-wise here?

#7 Updated by Rob Baer almost 3 years ago

  • Target version changed from MakeHuman 1.1.0 to MakeHuman 1.2.0

This should continue as exporters are tested and solidified.

#8 Updated by Joel Palmius almost 2 years ago

  • Priority changed from High to Low
  • Target version changed from MakeHuman 1.2.0 to MakeHuman 1.1.2

As we're no longer treating MHX2 as something the cat thought would make a nice present to put on your pillow, I'm thinking the issue has less relevance, but that it's also easier to pick off.

Going to take a look at the documentation status for 1.1.2.

Also available in: Atom