Re-using materials on meshes with different attributes
hybridherbst opened this issue · 3 comments
Related to
glTF is used more and more for interchange usecases. Even if glTF may not have been designed with that in mind, it is what it is.
Some of the spec make that hard, for example the requirement that all accessed attributes MUST exist on a primitive, or else the file is valid.
As an example, reusing a material that puts a texture in UV1 on a mesh that only has UV0 results in an invalid file. To make the file valid, the material must be duplicated, which increases the amount of data transmitted and reduces the usefulness for interchange. If the material is animated (e.g. with KHR_animation_pointer) then there is even more data to be duplicated to make sure the resulting file is still "validator valid".
Applications treat that differently right now. Because reusing materials in this fashion is very common, and nobody likes to suddenly have two materials instead of one to author, many applications seem to have opted for making it work nonetheless.
The attached file ✅ works / ❌ fails in
✅ Babylon
✅ Gestaltor
✅ Unity
✅ Unreal
✅ Khronos Sample Viewer
❌ three.js/model-viewer
❌ glTF Validator
UV missing in one object
UVMismatch_UV1.glb.zip
UV missing in all objects
UVMismatch_UV2.glb.zip
Personally I think it would be better if this was allowed, and there were clear rules what happens when accessing attributes that don't exist.
Behaviours found in the wild:
- last valid attribute of that sort is used (e.g. when UV0 and UV1 are defined and UV2 is accessed, UV1 is used) (Unity does that)
- placeholder attribute is filled with zeros (Gestaltor/Khronos Sample Viewer/Babylon do that)
- entire scene stops rendering (three.js)
Inconsistent behavior for an explicitly invalid asset layout is a strong reason to not change the spec. Engines that do not crash on the example assets may do so with slightly different assets exhibiting similar layouts.
A simple EXT extension could be defined that relaxes this requirement, i.e., changes
A mesh primitive MUST have the corresponding texture coordinate attributes for the material to be applicable to it.
to:
A mesh primitive SHOULD have the corresponding texture coordinate attributes for the material to be applicable to it. [Description of how to treat materials missing UVs.]
Such an extension would have to be present in the asset's extensionsRequired array.
Would you say the same applies for MaterialX/procedurals in the context of glTF? E.g., do I need many, many almost-exact copies of material graphs in the same file just because some meshes don't have specific UV coordinates?
Since there is no ratified extension for using MaterialX graphs with glTF 2.0, little could be said about its limitations. At the very least, I'd expect some kind of instancing system as the same graph could be used with different inputs/outputs, regardless of UV sets.