Custom semantics in morph targets?

[lexaknyazev]

The spec says:

Application-specific semantics must start with an underscore, e.g., _TEMPERATURE.

The spec should be more explicit whether this applies to morph targets (I'd say yes).

/cc @bghgary @donmccurdy @emackey

[donmccurdy]

I would say yes as well; that seems to follow from the requirement that morph target names match the vertex attribute semantics. The requirement should apply to semantics in general, regardless of their use.

[lexaknyazev]

@bghgary @emackey any objections?

[emackey]

Agreed with Don.

…

On Sat, Jun 30, 2018, 8:21 AM Alexey Knyazev ***@***.***> wrote: @bghgary <https://github.com/bghgary> @emackey <https://github.com/emackey> any objections? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1363 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLYiM_ufJm1EfpdEmbkOEX9LeDx-iF5ks5uB21FgaJpZM4UcMhP> .

[bghgary]

Sounds right to me.

[donmccurdy]

Oh, the spec also states:

Each target ... 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.

So, morph targets on COLOR and application-specific semantics would not be allowed without an extension.

[lexaknyazev]

It says "supported", not "allowed". As far as I remember, there wasn't any intention to disallow custom attributes in morph targets. Could we check with implementations?

[donmccurdy]

Ah, I see. three.js will ignore unknown morph target attributes, but the asset will load fine.

[donmccurdy]

Opened #1464.

[donmccurdy]

It says "supported", not "allowed". As far as I remember, there wasn't any intention to disallow custom attributes in morph targets.

Maybe I'm picking nits here, but how would you define "supported"? If an implementation is allowed but not required to write/read morph targets on application-specific semantics, would an implementation be allowed but not required to write/read morph targets on COLOR?

If the meaning was simply that implementations don't have to support COLOR morphing I'd implement it in a second. 😇

[lexaknyazev]

Morphed COLOR is definitely interesting.
Current spec language could be interpreted the same way as the case with having three UVs (which is technically allowed but not widely supported).

[emackey]

currently only three attributes (POSITION, NORMAL, and TANGENT) are supported.

So, "supported" is a reference to existing implementations? Maybe we could clarify that, something along the lines of:

Currently only three attributes (POSITION, NORMAL, and TANGENT) are commonly supported, but others such as COLOR and even application-specific semantics that start with an underscore (e.g., _TEMPERATURE) are allowed.

[donmccurdy]

Copying comment (#1464 (comment)) here:

Similar to TEXCOORD_2, should we go a bit farther than that and say that any attribute may be affected by morph targets, and clients must support at least POSITION?