KhronosGroup
"Positive rotation is counterclockwise" in section 3.4 is an ambiguous statement
In general, words like clockwise and counterclockwise only work in the context of a completely fixed 2D coordinate system, and even then I wouldn't recommend using it because of all the transformations we do!
The ambiguity
Say, from the perspective of a viewer:
- If Z is forward, X is left, and Y is up, a positive rotation around Z is clockwise
- If Z is back, X is right, and Y is up, a positive rotation around Z is counterclockwise
This is ambiguous! Note that both of these are right handed, just like the spec says
Disambiguating
A handedness independent way to describe rotations in, say, an XY or UV plane, is to say that
- In the XY plane, positive rotations go in the angular direction of the shortest rotation from the X axis to the Y axis
- The same rule applies to all other planes too!
- a positive YZ plane rotation goes from Y to Z
- a positive ZX plane rotation goes from Z to X
- a positive UV plane rotation goes from U to V
A more general and accessible way to describe positive rotation direction in any plane/around any axis, without getting bogged down in technical details like cross products or determinants, would be to say that gltf follows the right hand rule for both rotations and triangle winding.
If you make a thumbs up gesture with your right hand, then if your thumb is a rotation axis, the curl of your fingers will tell you the positive rotation direction. This applies to triangle winding as well - if the curl of your fingers follow the vertex definition order spatially, your thumb represents the face normal, if a right handed winding order is used.
Here's an infographic I made a while back! As far as I've been able to tell, this is a consistent rule that should apply across the board, from rotations, windings, cross products, 3D space, and UV space. It seems to be the most mathematically pure way to define rotation ordering, and to avoid all sign errors. If you deviate from this, the implementation is likely flawed and will cause sign errors throughout the codebase, which will only cause more headaches down the line in search of landing at the next stop of, an even number of sign errors c:
I saw there was a similar PR on this before but it seems like it didn't go anywhere and also was getting wrapped up in technical solutions for what I think can be more easily explained geometrically!
If you make a thumbs up gesture with your right hand, then if your thumb is a rotation axis, the curl of your fingers will tell you the positive rotation direction.
I'd say that the thumb here is the direction of the face of the clock, and that the fingers (that describe a positive rotation) then indeed point in counterclockwise direction. But maybe there is an ambiguity that I don't see, and a sensible way to resolve that.
An aside: I don't understand what is meant by the statements like
a positive YZ plane rotation goes from Y to Z
If you make a thumbs up gesture with your right hand, then if your thumb is a rotation axis, the curl of your fingers will tell you the positive rotation direction.
I'd say that the thumb here is the direction of the face of the clock, and that the fingers (that describe a positive rotation) then indeed point in counterclockwise direction. But maybe there is an ambiguity that I don't see, and a sensible way to resolve that.
The way I resolve it is to just not use a clock! especially in 3D where there's always an axis to rotate around, the right hand rotation rule is enough on its own. The ambiguity with the clock analogy lies in whether you care more about the direction of the face of the clock (pointing toward you, away from the wall) or the direction the clock was attached in (pointing away from you, toward the wall), and that ambiguity is unstated right now.
In most cases this probably doesn't matter that much to most people! but I think a spec should be extra clear to resolve ambiguities like this
An aside: I don't understand what is meant by the statements like
a positive YZ plane rotation goes from Y to Z
The idea is that the shortest rotation that would rotate the vector X (1,0,0) to Y (0,1,0) - that rotation direction is always positive, regardless of handedness or up axis or whatever else! The same goes for any two basis axes, whether it's XY or YZ or ZX or UV. like this! (I also edited OP to make this a little more clear now)
This sounds like (referring to the left image), that rotation around the Z-axis is "positive", regardless of whether the Z-axis points 'into' the screen or 'out of' the screen (unless the z-axis is assumed to out 'out of' the screen there - otherwise, that would contradict that "curling fingers" rule). But maybe I'm still overlooking something, so hopefully, others will chime in here with thoughts about how that statement from the spec could be changed to avoid confusion.
This sounds like (referring to the left image), that rotation around the Z-axis is "positive", regardless of whether the Z-axis points 'into' the screen or 'out of' the screen (unless the z-axis is assumed to out 'out of' the screen there - otherwise, that would contradict that "curling fingers" rule). But maybe I'm still overlooking something, so hopefully, others will chime in here with thoughts about how that statement from the spec could be changed to avoid confusion.
Changing the Z direction will also change the handedness, and thus also change which hand you're using for the right/left hand rule for rotations/winding!
So this image here, where X is right and Y is up, is in one of two possible states:
- A right-handed coordinate system where Z is pointing towards you, where the curl of the right hand rule for rotations matches my blue rotation marker
- A left-handed coordinate system where Z is pointing away from you, where the curl of the left hand rule for rotations matches my blue rotation marker
And so because gltf is already right-handed by definition, that rules out the second possibility, and so the ambiguity is resolved
I'm a stickler. And sometimes, I'm a bit slow. But I'd like to explain my confusion: I misinterpreted the part that said
The idea is that the shortest rotation that would rotate the vector X (1,0,0) to Y (0,1,0) - that rotation direction is always positive, regardless of handedness or up axis or whatever else! (Emphasis by me)
Maybe I wouldn't have misunderstood that if it had been "depending on the handedness"? Writing things in a way that is concise, easy to understand, and as precise as they have to be for a specification is an art. And for me (and many other people) there's also the language barrier. What may be "clear and obvious" for a native speaker may still require a certain "depth" (or intuition) of understanding that not everybody has...
So ... on the one hand (... that nearly sounds like a pun right now...?) I'm all in favor of writing things in a way that reduces ambiguities. The coordinate conventions did raise questions ...
- https://github.com/KhronosGroup/glTF/issues/1640
- https://github.com/KhronosGroup/glTF/pull/2139
- https://github.com/KhronosGroup/glTF/issues/2149
- https://github.com/KhronosGroup/glTF/issues/2352
- this one 😁
- ...
And this was despite all previous efforts to be clear and precise and unambiguous.
On the other hand, I wonder how the spec text could be improved here. What you described sounds like a form of "generalization". But given that glTF is constrained to already use a specific (right-handed) coordinate system convention, I wonder what the exact wording could be.
Currently there is the (short, concise, easy-to-understand, but maybe ambiguous) statement
in the specification. What exactly should there be instead?
Yeah, I agree that there's no need to go the generalized route when gltf is squarely in the right handed realm! I think there are two options here:
Option 1: Remove the line
That line actually not technically necessary, because the fact that gltf uses is a right handed coordinate system, does (if implemented correctly) resolve ambiguities around this. However, words like clockwise are pretty intuitive to people who aren't already intimately familiar with how handedness and rotations work, so there's probably some value in keeping it in some form
Option 2: Keep the line, but resolve the ambiguity
This can be done by explicitly spelling out the axis of rotation.
Positive rotations follow the right hand rule. In other words, if the axis of rotation is pointing toward you, positive rotations are counterclockwise
using an image like this to visualize the right hand rule for rotations would also be really helpful I think! ie: your thumb and the yellow arrow here is the axis of rotation, and your remaining fingers show the positive rotation direction. It might also be worth it to mention how triangle winding also follows this same rule.
I can make a version of this image with a white background and all so that it fits the documentation better if you'd like to use it!
The second option sounds reasonable for me. (But ... I'm not important in that regard...)
About the image... well.
(An aside: There currently are some ongoing considerations to replace the boom box image that shows the axes with another one. Actually, the ISO version of the glTF specification uses a different image, and one of the goals is to use the same image for both the online- and the ISO version. This has been considered for... maybe a year now?)
Images are difficult. And particularly images of hand gestures. And even more particularly that of a "Thumb up". While it is generally a sign of agreement nowadays (and I already see two 👍 on your initial post), this gesture did have a pejorative meaning in some cultures until recently, and people still tend to be very careful with things like that for any form of "official documents"...
No strong opinions from my side, though. I'm still wondering whether others may chime in here....
I would guess a thumbs up gesture isn't something to be worried about anymore for anyone connected to the internet, especially now that it's universally been used to represent a "like" online, on top of being pretty explicitly used for an illustrative and geometric purpose in this case, and not an ambiguous gesture up open for misinterpretation without context