Collada --> Blender Pipeline missing clothing texture detail
|Target version:||MakeHuman 1.1.2|
r1698 on Windows
Compare export-import throughput using .mhx2 and .dae. Notice that bump/normal map for shirt seems more robust using .mhx2 than using .dae. Sample images use meter scale for throughput.
Note that .fbx scaling import is WAY off (microscopic model) and was difficult to include for addional comparison as well as causing console errors during import. I am theefore not even including those images.
As complex as .mhx2 may be, there appear to be some clear benefits to using it in the MH --> Blender pipeline if one wishes to retain reliable throughput (even without considering .mhx2 advanced features like support for cycles materials).
Related issue #546. See also other collada issue 515, 586, 594, 624
I note that there are issue categories for FBX and MHX (which will be no longer official), but not for collada so I am tagging this code correctness until we get a DAE issue category.
#4 Updated by Anonymous almost 4 years ago
Side note: Blender dae (and fbx support) is improved in Blender 2.73: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.73/Addons
#6 Updated by Rob Baer almost 4 years ago
The Khronos group has a conformance test suite for collada: https://www.khronos.org/files/collada/COLLADA-CTS-Tutorial.pdf
If we commit to collada-based pipelines perhaps deveoping the python script required to use it would be worth the effort. On the other hand perhaps this is overkill, given support level downstream in the pipeline. But, to make open standards work a critical mass of people have to contribute and someone needs to go first.
As a bonus, wouldn't this be a useful side-project to help spark further development of Joepal's scripting interface for MH?
#7 Updated by Jonas Hauquier almost 4 years ago
In the past I have compiled the khronos collada validator and ran it on some mh exports. Everything was fine.
Of course, I'm not sure this checker does much more than checking the structural correctness of the files (validation of the XML DTD).
I have taken a look at the full test suite in the past, and found that most tests are aimed at tools that manipulate COLLADA content in more traditional editing ways, for example some of the functions that blender performs. But I didn't see much opportunity for testing MH related functions. After all, we don't support anything in terms of COLLADA authoring, the only thing we can do is export such a file. No round-trip support, no editing, ...
#8 Updated by Rob Baer almost 4 years ago
Blender bug tracker provided the following feedback:
@rwbaer Transparency issue : already mentioned here T27161. Transparency value is exported to the collada file, but in the collada libs there is no way to access transparency(unless there is a workaround).. so it can be fixed only when libs are fixed.(See COLLADAFWEffectCommon.h, there is api for getting value from collada file like getShininess () etc., but not for transparency.. for some reason parts of code are commented out i.e. mTransparency, mTransparent)
Not quite sure what this means for us, but I'll keep poking around.
#9 Updated by Rob Baer almost 4 years ago
There was some patch activity, and the Blender issue was closed. Seems it may take some time to make it into Blender nightlies.
Here's hoping it will improve MH -> Blender pipeline!
#11 Updated by Rob Baer almost 4 years ago
Blender Dev does not appear to openly share email contacts:
With a little googling, Gaia Clary's public blog contact seems to be: http://blog.machinimatrix.org/author/gaia/
The Blender "ground-zero" TODO URL for Collada issues seems to be:
#15 Updated by Rob Baer almost 4 years ago
- Category changed from Code correctness to File export
To clarify, MH issue #679 (this one) and the Blender bug report above was about importing 'normal map textures' and that is the issue I'm hopeful that we got some traction on, but I'm not certain yet...
In reporting normal maps, I committed the cardinal sin of mentioning the "transparency issue" in the same bug report. I think there is no traction on transparency import, but we did get this response that may provide some insight into the issues related to a transparency import fix:
sauraedron (Saurabh Wankhade) added a comment. @rwbaer Transparency issue : already mentioned here T27161. Transparency value is exported to the collada file, but in the collada libs there is no way to access transparency(unless there is a workaround).. so it can be fixed only when libs are fixed.(See COLLADAFWEffectCommon.h, there is api for getting value from collada file like getShininess () etc., but not for transparency.. for some reason parts of code are commented out i.e. mTransparency, mTransparent)
The "lack of "implementation" and "commented out" code seems strange indeed, but I'm not really capable of investigating "work-arounds". Looks like we are talking C code that has been intentionally disabled for "unknown reasons".
#16 Updated by Jonas Hauquier almost 4 years ago
Rob Baer wrote:
To clarify, MH issue #679 (this one) and the Blender bug report above was about importing 'normal map textures'
Ah, right. In that case I believe progress is made. :)
About the transparency: yes, I believe Blender has native code for the DAE importer.
Also available in: Atom