Bug #1148

Test/fix collada pipeline vs various external platforms

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

Status:NewStart date:03/12/2017
Priority:NormalDue date:
Assignee:Joel Palmius% Done:

0%

Category:File export
Target version:MakeHuman 1.1.2

Description

The path from MH to blender is a bit bumpy, with for example the need to manually edit many materials after import to add an alpha channel.

Since collada is one of the few actually open and documented 3d exchange formats, maybe it'd be a good idea to make pipelines using this a bit smoother. Not only to blender but also to unity (which seem to have a native support for collada) and maybe other platforms which also support collada.

The first thing which needs to be done is map the current situation and test collada a bit here and there to see what the status actually is.

(It's entirely possible the resolution of the issue is that collada support sucks everywhere and that there's nothing to be done about it)


Related issues

Related to MakeHuman - Bug #934: Collada does not import textures Fix exists, needs testing 07/19/2015
Related to MakeHuman - Bug #1025: Crash in collada export when checking facial pose-units Accepted 05/11/2016
Related to MakeHuman - Bug #1042: MakeWalk Load and Retarget with Collada export New 07/06/2016
Related to MakeHuman - Bug #679: Collada --> Blender Pipeline missing clothing texture detail New 01/30/2015
Related to MakeHuman - Bug #1084: Empty tags in materials of COLLADA files New 12/16/2016
Related to MakeHuman - Bug #515: Exporters are of Variable Fidelity in moving assets New 09/03/2014
Related to MakeHuman - Feature #984: Torque3D compatible collada export option Accepted 01/08/2016
Related to MakeHuman - Bug #546: Collada material properties incorrect for transparent obj... Accepted 10/06/2014
Related to MakeHuman - Bug #624: Blender Collada import has problems with rigs New 11/02/2014
Related to MakeHuman - Bug #1001: Collada export produces (skeleton) warnings on Maya import New 03/06/2016

History

#1 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #934: Collada does not import textures added

#2 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #1025: Crash in collada export when checking facial pose-units added

#3 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #1042: MakeWalk Load and Retarget with Collada export added

#4 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #679: Collada --> Blender Pipeline missing clothing texture detail added

#5 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #1084: Empty tags in materials of COLLADA files added

#6 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #515: Exporters are of Variable Fidelity in moving assets added

#7 Updated by Joel Palmius almost 2 years ago

  • Related to Feature #984: Torque3D compatible collada export option added

#8 Updated by Joel Palmius almost 2 years ago

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

#9 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #624: Blender Collada import has problems with rigs added

#10 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #1001: Collada export produces (skeleton) warnings on Maya import added

#11 Updated by Joel Palmius almost 2 years ago

  • Description updated (diff)

#12 Updated by Aranuvir # almost 2 years ago

The path from MH to blender is a bit bumpy, with for example the need to manually edit many materials after import to add an alpha channel.
[...]
The first thing which needs to be done is map the current situation and test collada a bit here and there to see what the status actually is.

Some quick tests: import a model into Blender (2.78c, internal render engine) via mhx. Surprisingly, all the textures are correct. No export the model as collada file and reimport it into Blender, and the transparency is gone. => Blender collada seems to be broken. Further Blender investigations do not make sense until they get their tools fixed. Probably we need some other tools to check our collada exports.

#13 Updated by Rob Baer almost 2 years ago

A couple of years ago, I spent quite some time testing FBX and Collada exporters against multiple downstream programs as Manuel was divesting .mhx support in favor of open source (see some of the cross-references above). My sense was that the industry was beginning to abandon collada because of the Autodesk SDK and Autodesk's SDK. What was remarkable for Blender, 3DSMax, or Maya was that both formats did not make good import/export/import round trips easy with MakeHuman.

One consistent stumbling block is using the of the texture file for specifying transparency on body textues. Joel has found the same in Unity. In all programs it can be done this way, but in none is it the "go to" method and is always the first thing that needs correcting with these generic asset formats. This is one thing that makes .mhx2 superior and easier to use. Further, Blender cycles gets no "help with the basics" for either format. Nicely,Thomas finally took this one on as well. My wiki workflows. like Joel's for Unity, are largely about how to repair transparency in downstream programs.

As to Blender Collada, its greatest supporter is Gaia Clary of Avastar fame. Not everyone else seems to think collada is still relevant. See here: https://code.blender.org/2016/10/the-collada-case.
I've stopped looking at these things since it became "no longer sinnful" to say .mhx2

FBX works fine to get to Maya or 3DSMax or Unreal Engine (or Unity I think ??) except for the need to fix teansparency. Note that the way we do transparency won't survive export and reimport by these programs. One might even be tempted to start thinking it is "non-standard".

The handling of export scaling has seemed to off and on worked fine but usually more reliably in collada than FBX. This often requires in Blender remembering whether to check ignore scaling with the collada importer. Importer changes in other software often obviate corrections we make to our exporters.

Finally, local axes on bones, whether or not rotations are applied on import as we convert from y-up makehuman to z-up blender can cause problems. The local axis thing was a major discussion on the UE site some time back, but I don't know the final verdict.

Oh yeah, and then there is the Blender bones we know and love and the joint-like bones used by others which involves leaf-bones ...

#14 Updated by Aranuvir # almost 2 years ago

Rob Baer wrote:

[...] My sense was that the industry was beginning to abandon collada because of the Autodesk SDK and Autodesk's SDK. What was remarkable for Blender, 3DSMax, or Maya was that both formats did not make good import/export/import round trips easy with MakeHuman.

What is remarkable is that Blender obviously does not use the SDK, but its own script and MakeHuman uses the Blender scripts. Probably a source of problems. (https://en.wikipedia.org/wiki/FBX#Limitations) and from io_scene_fbx/__init__.py:

bl_info = {
"name": "FBX format",
"author": "Campbell Barton, Bastien Montagne, Jens Restemeier",
"version": (3, 7, 7),
"blender": (2, 77, 0),
"location": "File > Import-Export",
"description": "FBX IO meshes, UV's, vertex colors, materials, textures, cameras, lamps and actions",
"warning": "",
"wiki_url": "http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Autodesk_FBX",
"support": 'OFFICIAL',
"category": "Import-Export",
}

#15 Updated by Rob Baer almost 2 years ago

Aranuvir (Moderator) wrote:

What is remarkable is that Blender obviously does not use the SDK, but its own script and MakeHuman uses the Blender scripts. Probably a source of problems. (https://en.wikipedia.org/wiki/FBX#Limitations) and from io_scene_fbx/__init__.py:

Yes, I think Blender's decision to not use the SDK but to reverse engineer a version reflected licensing issues and the open source rigor of that development team. However, Maya FBX export | Maya FBX import is not always a safe round trip. 3DSMax Export | 3DSMax import is not always a safe round trip. And Max to Maya via FBX or vice versa has problems as well. The SDK is not the whole answer. Open formats are not designed for a specific purpose. I think it is best to think of them as work-arounds not solutions.

This is one of the things that intrigues me about the notion of extended Thomas' MHX2 importers to other important platforms. We could let the MakeHuman assets get there in one piece at least. We'll see where this falls on the priority list after py3 port is done.

#16 Updated by Jonas Hauquier almost 2 years ago

Yes, that was the idea. Shipping open source software that is dependent on proprietary SDKs is not a good way to go.

The problem with MHX was similar to that of FBX: it was not documented. So it basically had the same problems with maintainability, stability, and extending on it that these other formats had.
Also the effort of maintaining importers for different 3D tools should not be underestimated. It will probably require dedicated developers per software.

Also available in: Atom