node.matrix > node.trs ?

[andreasplesch]

#12 introduced the notion that both a matrix and TRS could define the local transform of a node. At the time this seems to have been considered from the point of view of converters which would then have options to do one or the other.

However, now with both options available in the spec. and gltf becoming more widely used, the spec. probably needs to deal explicitly with the possible situation that a node specifies both ways to define a transform.

Options could be:

• declare glft invalid or any effects/node render results undefined
• prefer matrix over trs or vice versa
• apply both, trs then matrix, or matrix then trs

A possible use case could be that a converter decides it is a good idea to offer both options in case the node is used sometimes in an animation but most of the times statically. Not saying that this is likely but not out of the question.

Another use case may be handcrafted gltf where the author just uses the spec. literally.

#745, #743, #13

[Also, I did not find a statement regarding duplicate keys in the json: last one wins ? ]

[lexaknyazev]

possible situation that a node specifies both ways to define a transform

That's incorrect - glTF 1.0 explicitly says:

A node can have either a matrix or any combination of translation/rotation/scale (TRS) properties.

Since animated nodes can't have node.matrix property, its main usage is to store static transform to skip matrix composition at runtime.

Other usage could be to store transformation not representable via TRS properties (such as shear). Should spec elaborate on that more?

CC @pjcozzi

[andreasplesch]

OK, I missed that. Perhaps add that in the case that both are defined, the glTF is invalid, to be very explicit.

I do not think it is necessary to elaborate on what values the matrix can have.

[andreasplesch]

I looked at a few glTF loaders and most seem to first check if there is a node.matrix value and if there is none use the node.trs value .

This means they allow for both transforms being present and if they are only use node.matrix.

Since loaders behave like this anyways, should this behavior be formalized in the spec. ?