Morph Target Names

[feiss]

It's not unusual to name morph targets so artists and programmers can refer to them by name, not index. An example in Blender:

But I don't see how 2.0 supports morph target names (https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#morph-targets). It seems it does not. Any thoughts on this?

[lexaknyazev]

glTF 2.0 uses integer indices to refer to different entities, because they're stored in JSON arrays. If an application wants to add string identifiers, it could use extras property like this (not a part of spec, just an example):

{
  "meshes": [
    {
      "primitives": [
        {
          "attributes": {
            "POSITION": 0
          },
          "targets": [
            {
              "POSITION": 1
            },
            {
              "POSITION": 2
            }
          ],
          "extras": {
            "targetNames": [
              "Happy",
              "Sad"
            ]
          }
        }
      ]
    }
  ]
}

[feiss]

Yeah I guess that could work

[donmccurdy]

Perhaps we should leave this open under glTF Next to consider named morph targets in a future version of the spec. It sounds like something that will be useful enough to implement via extras now, so bringing that into the spec eventually would be helpful.

[lexaknyazev]

Having two ways of doing something (in this case, referring to a morph target) isn't a good thing for data format in general.

I would think of some sort of "Pose" extension which could cover this use case as well as named and predefined skeleton states. Sometimes, model "emotion" consists of both skeleton transforms and morph weights.

[donmccurdy]

Having two ways of doing something (in this case, referring to a morph target) isn't a good thing for data format in general.

Right, if anything this should be similar to the name properties used on nodes — available as annotations for engines that use them (three.js and BabylonJS both do) but never used as references within the asset.

[takahirox]

I really want morph targets names as @feiss mentioned morph targets are often named for artists/programmers. I know Blender and other tools support morph targets names.

I think adding name property into targets elements is good (if morphTargets in glTF next is based on glTF 2.0). It's user-defined name, like node's, and isn't used as reference as @donmccurdy mentioned.

"primitives": [
  {
    "attributes": {
      "POSITION": 0
    },
    "targets": [
      {
        "name": "happy",
        "POSITION": 1
      },
      {
        "name": "sad",
        "POSITION": 2
      }
    ]
  }
]

[donmccurdy]

Another syntax option might be similar to what @lexaknyazev suggested, but without extras:

"primitives": [
  {
    "attributes": {
      "POSITION": 0
    },
    "targets": [
      {
        "POSITION": 1
      },
      {
        "POSITION": 2
      }
    ],
    "targetNames": [
      "happy",
      "sad"
    ]
  }
]

Could help with issues like KhronosGroup/glTF-Blender-Exporter#100, where the order of morph targets is not stable or obvious to the artist within a DCC tool.

[donmccurdy]

^The syntax above is easier because it doesn't break syntax and could potentially be in a 2.X release. Unfortunately I think @takahirox's suggestion would have to be considered a breaking change, based on:

Each target in the targets array is a dictionary mapping a primitive attribute to an accessor containing Morph Target displacement data, currently only three attributes (POSITION, NORMAL, and TANGENT) are supported.

If we were willing to break syntax, my vote might be to also move weights inline:

"targets": [
  {
    "name": "smile",
    "weight": 0.5,
    "attributes": {
      "POSITION": 1
    }
  }
]

[takahirox]

Ah, right. And in my suggestion having different types (indices to attributes and strings as name) in a dictionary isn't good. A bit complicate to parse.

I personally prefer the latter one because we don't need to care if "targetNames and weigts lengts are equal to targets length" and that name style is similar to node's and others. But the former one would be better because of non-breaking and less text size?

could potentially be in a 2.X release.

I hope this gets in.

[takahirox]

I came to think it'd better to have targetNames be under mesh like weights, not under primitive.

Is there any cases where we want different morph target name set across primitives, like

mesh.primitives[0]
  - targets[0] : "happy"
  - targets[1] : "sad"
mesh.primitives[1]
  - targets[0] : "smile"
  - targets[1] : "lonely"

?

[donmccurdy]

Oh, great point, I'd forgotten weights were on the mesh and not the primitive... worth noting that glTF animations target nodes, not primitives, and so having unrelated morph targets across primitives is probably something to discourage anyway.

"primitives": [
  {
    "attributes": {
      "POSITION": 0
    },
    "targets": [
      {
        "POSITION": 1
      },
      {
        "POSITION": 2
      }
    ]
  }
]
"weights": [0, 0],
"targetNames": [
  "happy",
  "sad"
]

[ziriax]

I got a request to add this to Maya2glTF. Has a decision been made regarding this? If not, any advice on what to pick for maximum compatibility with existing engines?

Thanks!

[donmccurdy]

@ziriax three.js looks for .extras.targetNames as a hint, on the mesh definition (not the primitive). Blender supports this on import, with a TODO to support it on export: KhronosGroup/glTF-Blender-IO#362.

[Ybalrid]

Looks like the mesh.extra.targeNames string array is getting some consensus. However this is not part of the specification. (Maybe something in a future 2.x version?)

In the mean time, would it be acceptable to add a non-normative "implementation note" to section §Concepts/Geometry/Meshes/Morph Targets

Something like that:

begin of text to add:

---

Implementation note: Although morph target are referenced by their position in the mesh.primitives[].targets array, many tools and application can use and benefit for having an associated name to a morph target. This functionality is not currently supported by the glTF 2.0 file format.

In practice however, many current implementation will check for the presence of an array of strings in mesh.extras.targetNames of the same size as the morph target array.

This practice is not currently standard. A future version of the glTF file format may include a standard way to store morph target names.

Each string of this array, if present, is a hint about the name of the morph target that can be presented in an user interface. See content of extras property in the example below :

"meshes": [{
	"extras": {
		"targetNames": [
			"target_Smile",
			"target_Cry"
		]
	},
	"weights": [
		0,
		0
	],
	"primitives": [{
		"attributes": {
			"POSITION": 0,
			"NORMAL": 1
		},
		"targets": [{
				"POSITION": 2,
				"NORMAL": 3
			},
			{
				"POSITION": 4,
				"NORMAL": 5
			}
		],
		"indices": 6
	}]
}]

---

end of text to add

I would like to open a PR to implement the proposed addition...
Any suggestion about this? (I know the pasted JSON section is probably a bit too much -- I'll probably leave it out.)

Edit: This could also be formalized in an tiny extension? Would that be worth it? The extras parameters is already implemented in a number of places, for example the blender gltf plugin...

[donmccurdy]

I'd definitely like to see targetNames added in whatever the next version of glTF is. Whether we should do anything additional in the meantime, I'm not sure... it feels a little silly to make such a small extension, even though it isn't much trouble. But documenting .extras.targetNames in the official spec feels a bit weird too. 😕

[Ybalrid]

Hey @donmccurdy thanks for your input!

For me, It really depends on when "the next version of glTF" will happen... If it's in a little while, well, maybe we should bother with explaining the stop-gap solution?

Such an extension is indeed a bit silly, and like you I also feel like it is a bit strange to have documentation about an extra field (that is supposed to exist to be able to add application specific things to the glTF format if I understand the design logic behind extras properties).

It is just that I had to google for and find this discussion for finding the answer for "is there a way to get the name of morph targets in a glTF?" And I found this, and that the exporter in the lattes beta of blender 2.8 I downloaded was writing this array of strings, so I could use that directly.

I am aware of another exporter that also bother exporting target names in that way, and I think your glTF webGL viewer (three.js based?) also can read these names and show them in the UI, but I haven't checked this usage was super widespread among software compatible with glTF. Judging by the number of times this issue has been referenced by external repository discussions using the # feature of GitHub markdown, it seems that whether or not we hint about this in the main document, people are today writing software that check if that property exists and loads it's content anyway.

It is not ugely important, and not all application that consume glTF assets needs to have names for their morph targets, it's just a "nice to have feature".

What I suggest is obviously not to set in stone the extras property at all, it's to add a pointer as a non-normative note that this is a relatively common usage of mesh.extras.targetNames. I don't really know if it's a good idea, I'm just asking for input here.

I have updated my comment above to add a blurb explicitly saying "this is not standard, a future version of glTF may do this differently".

Personally, I think this is so small of a thing that it doesn't deserve an extension. However, some extensions like KHR_materials_unlit are also way smaller. (it's only content is "does it exist on this material") so maybe a mesh could have an XXX_target_names extension field that contains morph target names as a simple array of strings ? But in that case, instead of having 1 "non standard" way of doing things, we would have 2 (or 1.5 if you consider the fact that extensions are documented here to be also part of the file format specifications, but are more akin to "optional additions").

[donmccurdy]

There is no ETA on glTF 2.X or 3.0 at this time – we are currently focused on extensions.

I'd be OK with adding a non-normative implementation note in the spec. Any objections?

[Ybalrid]

Okay. If you guys are on board with it I will open a PR with my proposed addition later today. We will be able to discuss the actual wording in that comment section. 😄

…

Le 18 juin 2019 à 02:03, Don McCurdy ***@***.***> a écrit : There is no ETA on a new version of glTF 2.X or 3.0 at this time – we are currently focused on extensions. I'd be OK with adding a non-normative implementation note in the spec. Any objections? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Ybalrid]

I've opened PR #1631. If you agree that's a good idea, we can go discuss the actual wording to add to the document here.

[donmccurdy]

Implementation note (#1631) has been merged. Leaving this issue open under the "glTF Next" milestone, so that we can consider something in the spec when we get there.