Add non-normative note about the current usage of mesh.extras.targetNames #1631
Conversation
…ames Morph target names are not required to perform morphing. A real time application that consume glTF assets doesn't need morph target names in the general case. Rightly so, glTF doesn't impose assets to have target names, but it also doesn't provide a way to optionally add them. It seems that, since the release of glTF 2.0 in mid-2017, a number of implementation (three.js, the official Blender exporter, UnityGLTF, a and at least one Maya exporter (and probably some others software, I haven't made a list, these are the few I'm aware of)). This has been discussed in issue KhronosGroup#1036. The goal is to help implementations that wants to do so have a way to do so in an interoperably way. Currently this has been done by adding a `targetNames` extras properties to the object. Maybe a more proper way would be to have an extension doing so, however, this practice is already quite widespread, so I would argue that at least documenting it here and integrate a better (and standardized) way of doing so in glTF 2.x/3.0 is the better thing to do. I am not opposed to the idea of writing an extension to support morph target names, but that would add 2 *not really standard* way of doing it instead of the one already out in the wild.
|
Thanks! I'm in favor of adding the note, but would shorten it and omit the example:
|
|
Hey @donmccurdy I agree with your proposition, it is way more concise and does tell basically the same information. So, I have removed the example, and I have updated the note to what you proposed. I have replaced "list" by "array" (as these are JSON indexed "array"). |
|
I think it's good to be merged now? |
|
@lexaknyazev or @bghgary Any thoughts before this gets merged? |
|
Ok to me. |
|
Thanks for proposing the addition @Ybalrid! |
|
@donmccurdy Thanks for accepting it 😉 |
Morph target names are not required to perform morphing. A real time application that consume glTF assets doesn't need morph target names in the general case.
Rightly so, glTF doesn't impose assets to have target names, but it also doesn't provide a way to optionally add them.
It seems that, since the release of glTF 2.0 in mid-2017, a number of implementation (three.js, the official Blender exporter, UnityGLTF, a and at least one Maya exporter (and probably some others software, I haven't made a list, these are the few I'm aware of)).
This has been discussed in issue #1036.
The goal is to help implementations that wants to do so have a way to do so in an interoperably way. Currently this has been done by adding a
targetNamesextras properties to the object.Maybe a more proper way would be to have an extension doing so, however, this practice is already quite widespread, so I would argue that at least documenting it here and integrate a better (and standardized) way of doing so in glTF 2.x/3.0 is the better thing to do.
I am not opposed to the idea of writing an extension to support morph target names, but that would add 2 not really standard way of doing it instead of the one already out in the wild.