Empty tags in materials of COLLADA files
|Assignee:||Jonas Hauquier||% Done:|
|Target version:||MakeHuman 1.1.2|
The materials of the exported COLLADA files - particularly, the
phong element - contain empty tags/elements for several properties:
<technique sid="common"> <phong> ... <shininess><float>128.0</float></shininess> <normal> </normal> <bump> </bump> <displacement> </displacement> </phong> <extra/> </technique>
The relevant part of the COLLADA schema is this:
<xs:element name="phong"> <xs:complexType> <xs:sequence> <xs:element name="emission" type="fx_common_color_or_texture_type" minOccurs="0"/> <xs:element name="ambient" type="fx_common_color_or_texture_type" minOccurs="0"/> <xs:element name="diffuse" type="fx_common_color_or_texture_type" minOccurs="0"/> <xs:element name="specular" type="fx_common_color_or_texture_type" minOccurs="0"/> <xs:element name="shininess" type="fx_common_float_or_param_type" minOccurs="0"/> <xs:element name="reflective" type="fx_common_color_or_texture_type" minOccurs="0"/> <xs:element name="reflectivity" type="fx_common_float_or_param_type" minOccurs="0"/> <xs:element name="transparent" type="fx_common_transparent_type" minOccurs="0"/> <xs:element name="transparency" type="fx_common_float_or_param_type" minOccurs="0"/> <xs:element name="index_of_refraction" type="fx_common_float_or_param_type" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>
To my understanding, these empty tags may not appear in the
phong element (otherwise, some trickery would be required in the schema, to allow "any" additional elements).
These empty tags cause validators and COLLADA parsers to choke on the given input.
From a quick glance at the source code, the cause seems to be in the file
but I'm not sure about the best way to fix this.
(Note: I can imagine that the answer to this issue will be something like: "Everybody is using these unspecified tags, and Blender expects them to be present, and there is no other solution for this". This would be perfectly fine. The fact that I'm currently working with a COLLADA loader that crashes due to these empty tags is a problem of the loader, of course. But I just wanted to point out that the exported files do not seem to be compliant with the schema spec nevertheless.)
#1 Updated by Rob Baer about 2 years ago
The ideal is to be true to the specification and have this result in no broken workflows. As you point out, sometimes the real world is not this ideal.
Can you share specifics on the validators and/or COLLADA parsers that are broken by the current MH collada export files? This at least provides a reproducible test case.
As to Blender, I have more than once had difficulty getting the Blender Collada Exporter to work with the Blender Collada Importer in a round trip fashion. I mention this because "the best way to deal with issues" sometimes boils down to which compromise you decide to make, not how to make things behave "properly".
If you spend a lot of time in the Collada world, please feel encouraged to continue sharing broadly-usable solutions to such problems. This might include additional commentary on trade-offs.
#2 Updated by Marco13 (Forum User) about 2 years ago
Sure, the COLLADA spec is a beast, and one always has to expect some glitches here and there. And of course, if such a change would break important, existing workflows (like Blender import), it cannot be done. There certainly are more important things than a formal non-compliance to a spec - especially if this non-compliance serves a goal that cannot otherwise be achieved.
I'm not really familiar with COLLADA, MakeHuman or Blender, so just wanted to mention it. But I cannot (yet) give suggestions or even recommendations about possible workarounds. From my (also limited) experience with XML parsers, I think that a common strategy is to simply ignore unknown tags (even though this means that non-compliant inputs can be read). This strategy may be a bad practice, and also may not be applicable for auto-generated parsers/validators, though.
However, the tool that choked on the exported file was https://github.com/KhronosGroup/COLLADA2GLTF/ . This was not a real, serious use-case. I just wanted to try creating a nice MakeHuman glTF sample model.
(BTW: I think that I spotted the relevant code paths that caused the crash there. They are not in the "core" parser part, but in the next step of the processing pipeline. The code can trivially be modified to graciously ignore the unknown tags, and I consider bringing this up as an issue/PR there as well).
The resulting glTF then has many further issues, of which I still can't say for sure whether they are caused by a "wrong" input or by further shortcomings in COLLADA2GLTF, but I'll try to allocate some time to analyze this in more detail.
But maybe the "solution" here is "simple": Did you ever consider to directly export glTF? :-)
#3 Updated by Marco13 (Forum User) about 2 years ago
I brought this up in https://github.com/KhronosGroup/COLLADA2GLTF/issues/10 . I'm sure we'll find a solution here without risking to break existing workflows.
#5 Updated by Marco13 (Forum User) almost 2 years ago
Note that, depending on the developments in COLLADA2GLTF for glTF 2.0, this issue might become obsolete.
The plan is to support PBR in glTF ( https://github.com/KhronosGroup/glTF/pull/643 ), and in the best case, it will then no longer be necessary to translate the techniques explicitly.
(All this is not yet finalized, but I wanted to leave the pointer here)
Also available in: Atom