Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify multi-node transform behavior with skew and shear #2328

Open
aaronfranke opened this issue Sep 16, 2023 · 2 comments
Open

Clarify multi-node transform behavior with skew and shear #2328

aaronfranke opened this issue Sep 16, 2023 · 2 comments

Comments

@aaronfranke
Copy link
Contributor

aaronfranke commented Sep 16, 2023

https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#transformations

The glTF specification section for node transformations contains this implementation note:

Implementation Note

Transformation matrices cannot skew or shear.

However, there is something left unclear. This seems to indicate that the glTF spec does not desire for skewed and sheared transformation matrices to exist in the file. However, it is possible to create a skew/shear by having a parent node with a non-uniform scale, and a child node with a rotation. There is a way to ensure skew/shear cannot be created by composition, by ensuring all transformation matrices are conformal, or by disallowing this configuration of a scaled parent with a rotated child.

So, questions:

  • What is the desired outcome of disallowing skewed/sheared matrices in glTF?
    • Is it to prevent skew/shear from happening? If so, what about the multi-node case?
    • Is it purely just to allow converting a node's local transform matrix to TRS? If so, why?
  • Is it allowed to create a skew/shear with multiple nodes like this?
    • If so, should it be discouraged to compose transforms like this in a way that creates skew/shear?
    • Should conformal transformations, where the only scale is uniform, be recommended for non-leaf nodes?
      • Things where non-uniform scale makes sense, like meshes, could be specified as leaf nodes.
        • However, skew/shear also makes sense with meshes, so that doesn't explain why skew/shear is disallowed.
  • If a glTF extension defines objects that cannot be skewed/sheared (as in the case with physics objects in most physics engines), or can't be non-uniformly scaled:
    • Is it acceptable for a glTF extension to impose additional restrictions on the glTF node transform, such that any files that create skew/shear are considered invalid?
    • Is it acceptable for a glTF extension to impose a conformal restriction so that the only allowed scale is uniform?
@lexaknyazev
Copy link
Member

What is the desired outcome of disallowing skewed/sheared matrices in glTF?

To allow converting a node's local transform matrix to TRS because some engines at the time of writing were accepting only TRS properties for node transforms. Initially, the node.matrix property was intended for storing precomputed TRS transforms for static nodes, hence the restriction on targeting such nodes by animations.

Is it allowed to create a skew/shear with multiple nodes like this?

Technically yes. This case has never been addressed explicitly.

Is it acceptable for a glTF extension ...

This may be tricky to enforce considering nested transforms and animations, e.g., if skewing or shearing appear only between keyframes.

@rotu
Copy link

rotu commented Oct 13, 2024

The TRS restriction has the unfortunate consequence that you can’t just “unparent” an arbitrary node and keep the same transform because that might be an illegal matrix.

Should conformal transformations, where the only scale is uniform, be recommended for non-leaf nodes?

I like the idea of restricting non-leaf nodes to conformal transforms. But even better, I like the idea of lifting the TRS constraint.

This may be tricky to enforce considering nested transforms and animations, e.g., if skewing or shearing appear only between keyframes.

Fortunately (and unlike TRS), the composition of conformal transforms is conformal. So I think it’s enough to check that no keyframe has non-uniform scaling. Am I missing something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants