Quaternion element order

[pwipf]

Please consider changing the quaternion element storage order back to x, y, z, w, as it was before version 0.9.9.6, before the change due to issue #916.

The change of the internal element order is a breaking change for many users of the glm quaternion library. A necessary feature of a useful low-level, high-performance library like glm is binary backward compatibility, and this is completely broken with this change.

I have no doubt that many users of glm quaternions have yet to pull the latest version and rebuild their projects. They will be surprised and once they figure out what happened, they will most likely (like me) revert to 0.9.9.5 and never upgrade again. I know that with a version 0, binary compatibility should not be relied upon, but I am sure I am not alone in expecting this basic element order to stay the same as it has been for many years.

I understand the reasoning for changing the order, per issue #916, but I have to say, this is a c/c++ library; the constructor element order is a very minor detail, easily worked around if you don't like it, while the underlying storage order is not.

By the way, I appreciate this library very much, and want to thank everyone who has helped make it great! I just want to add my perspective since I am sure this quat change will cause problems for many users of the library besides me.

A few arguments for changing the order back to x, y, z, w.

• Backward compatibility. There are many cases where quaternions are copied to disk (storage, retrieval), copied to pinned gpu memory for use in shaders, etc. Element-wise access for this type of use is a performance hit in many cases, not to mention convenience.
• Consistency. glm::vec4 is stored x, y, z, w, as are glsl vec4. I can name many libraries that store quaternions in this order. For example: Eigen.

Please consider this a humble petition to change the order back to x, y, z, w, and I would invite everyone who sees this to add to the arguments, or present counter-arguments.

[recp]

+1 for xyzw which is natural for GLSL and vec4

cglm was used wxyz order until v0.4.0 but we have changed it to xyzw a year ago (recp/cglm#43) in order to make it more compatible with existing APIs (like glm), existing formats (like glTF) and engines/libraries/...

just feedbacks.

[UX3D-becher]

+1 for glTF, where rotation animations are stored as xyzw quaternions to be binary compatible with glm. This allows engine developers to just memcpy data from a glTF binary buffer to a vector of glm::quat.

[Groovounet]

Thanks for reporting, I was concerned by breaking compatibility after this request which confirms GLM should not go this route.

Thanks!

[DomGries]

@Groovounet You didn’t yet revert the quat order changes of f5381ef#diff-13532d0c87d7f9f72136488d16205699 in glm/detail/type_quat.inl . Also the order change is still mentioned in the readme/changelog

[Groovounet]

Damn, that kind of hightlight some testing issues with the quaternion code... :/