Problems understanding how axis rotation works

[cesare.polonara]

Hi again, I got a new problem, I realized that during CSS transform rotations, the X axis ( green one ) is relative to the element axis, meaning that if the element rotates on Y or Z axis and the element X axis changes its space orientation, then the subsequent rotation on X axis is performed on the element new X axis orientation, while that does not work for Y and Z axes.
I made this visual example since I couldn't understand the behaviour during rotations and hoped a visual representation of the axes would have helped me...

I looked into transform specs https://www.w3.org/TR/css-transforms-2/#funcdef-rotatez but did not see anything mentioned, what am I missing ?
I feel pretty stupid right now since it looked like an easy task to perform sequential rotations, but I got stuck...

Thanks. 
 

UPDATE:

I realized the behaviour depends on the transform string order, meaning that the last rotate property written will make the axis relative to the element and not to the viewport, and it looks to me that GSAP places in the right order from right to left ( since transform string is composed from right to left according to specs ) rotateX, rotateY, and rotateZ. So if for example there's not a rotation on X axis then the rotation on Y axis will be relative to the element, but if there's a rotation on X that will be the only dynamic axis.

This thread maybe clears it: 

In the first pen of the trade he places scaleZ() as first to the right, that way the Z axis is dynamic and you can display the top face directly with a rotation on the viewport X axis.

In the second dice pen, if you check how it goes from number 4 to number 5, it does a sort of a hack, since at that point it's not possible to just make a 90° rotation on viewport X axis, since GSAP places it as dynamic.

I think you can see it here: 

See the Pen GRXqdON by kais3rp (@kais3rp) on CodePen

Both X and Z axis after number 4 shows are on the same axis.

I made this other codepen to try to understand how to display in specific orders the faces of a cube 

See the Pen JjaoywZ by kais3rp (@kais3rp) on CodePen

 but it looks like some movements are just not possible without hacking the order of the transform string...

See the Pen ZEMOJQR by kais3rp (@kais3rp) on CodePen

[Rodrigo]

Hi,

 

I think Jack (@GreenSock) is more suited to explain this, but this most likely is related with Gimbal Lock:

https://en.wikipedia.org/wiki/Gimbal_lock

 

Another option could be to replace the scaled dice with one that doesn't have any transforms applied to it, once the scale animation is completed.

 

Sorry I can't be of more assistance.

Happy Tweening!

[cesare.polonara]

16 minutes ago, Rodrigo said:

Hi,

 

I think Jack (@GreenSock) is more suited to explain this, but this most likely is related with Gimbal Lock:

https://en.wikipedia.org/wiki/Gimbal_lock

 

Another option could be to replace the scaled dice with one that doesn't have any transforms applied to it, once the scale animation is completed.

 

Sorry I can't be of more assistance.

Happy Tweening!

Yeah I stumbled upon the Gimbal Lock issue yesterday on a Unity forum, not sure if this is the case, or it's a limitation of how the browser composes the transform functions: https://henrikingo.github.io/presentations/3D study/plaincss.html .
Thanks anyway!

[GreenSock]

Yeah, it's an order of operation thing. 3D rotations can get mind-bending and gimbal lock is thorny. One of GSAP's strengths is its consistent order of operation. That's what allows you to animate each component (x, y, z, scaleX, scaleY, rotation, etc.) independently and always get clean results. In 99.9% of the cases, this is exactly what everyone wants. But if you've got one of those extremely rare edge cases where you actually want to CHANGE the order of operation, then you'd need to do that yourself in an onUpdate. You can still use GSAP to animate the values, of course, but you'd need to manage the strings. 

[cesare.polonara]

8 hours ago, GreenSock said:

Yeah, it's an order of operation thing. 3D rotations can get mind-bending and gimbal lock is thorny. One of GSAP's strengths is its consistent order of operation. That's what allows you to animate each component (x, y, z, scaleX, scaleY, rotation, etc.) independently and always get clean results. In 99.9% of the cases, this is exactly what everyone wants. But if you've got one of those extremely rare edge cases where you actually want to CHANGE the order of operation, then you'd need to do that yourself in an onUpdate. You can still use GSAP to animate the values, of course, but you'd need to manage the strings. 

Yeah I eventually found out that it's just the result of the mathematical composition of the functions from right to left!