Closed greggman closed 5 years ago
I found this thread while sorting through unexpected in/out tangents on frame 1 when exporting a simple animation using the latest KG glTF-Blender-IO plugin. But this is a separate issue that I'm still sorting out...
Having worked/developed extensively with r/t OGL graphics in broadcast, I'm sympathetic to @greggman 's points concerning accurate playback of the designers' animations. Arguments that dismiss his comments fail to grasp the reality of real-world implementations that have existed since the 1990s and are still in use today.
That said, @emackey makes the important distinction that glTF is a transmission/delivery (a.k.a., last-mile) format, and not an interchange format. Perhaps this issue should have been closed after his comment.
I found this related article by @meshula (Nick Porcino) that might be worth a read: Last-mile vs Interchange
Thanks, I think I will close this issue. The most practical option for Euler angles in glTF 2.0 is for exporters to understand the limitations of conversion to quaternions, and add extra keyframes as needed to make them work as best they can.
If there is a strong need for Euler angles to be stored directly in glTF, one of the vendors with that need should propose a glTF extension that can be used to identify which accessor holds the Eulers and what the structure of the data is.
AFAIK all animation packages, Maya, 3DSMax, Blender, etc store there rotation data as Euler rotations.
This is important because AFAIK Quaternions have no concept of spins larger than 1/2 a sphere. With Euler I can make an animation that spins around 4 times by setting just 2 keys. Key #1 = 0 degrees, Key #2 = 1440. With Quaternions AFAIK this can only be done by sampling the animation at some arbitrarily high sample rate where the sample rate must be high enough that no 2 keys rotate more than 180 degrees.