Fix constructor of struct qua to honor macro "GLM_FORCE_QUAT_DATA_WXYZ"

[blurgyy]

What

This makes the constructor of the quaternion struct qua behave more intuitively.

Why

The original version of the constructor takes four values (T _w, T _x, T _y, T _z), regardless of whether the macro GLM_FORCE_QUAT_DATA_WXYZ is defined. While the behaviours of the operator [] changes when the macro GLM_FORCE_QUAT_DATA_WXYZ is defined.

An illustrative example can be produced with the following code:

#include "glm/gtc/quaternion.hpp"
#include <iostream>

int main() {
    using quat = glm::qua<double, glm::defaultp>;

    // Initialized with constructor
    quat q1(0, 1, 2, 3);
    // Initialized by assinging values via operator[]
    quat q2;
    q2[0] = 0;
    q2[1] = 1;
    q2[2] = 2;
    q2[3] = 3;

    bool same = (q1 == q2);

    std::cout << std::boolalpha << same << std::endl;

    return 0;
}

The above code outputs false without -DGLM_FORCE_QUAT_DATA_WXYZ (because q1.w is 0 and q2.w is 3), and outputs true with -DGLM_FORCE_QUAT_DATA_WXYZ (expected).

This behavior is explainable as long as the author of the above code has previous knowledge about the implementation of the struct qua, but as the macro GLM_FORCE_QUAT_DATA_WXYZ is not defined by default, I think it's more intuitive to alter the behavior of the constructor of qua regarding this macro.

How

To achieve this, I have changed 2 files: glm/detail/type_quat.hpp and glm/detail/type_quat.inl.

• glm/detail/type_quat.hpp
  I removed parameter names in the declaration of the constructor (for readability), because the order of them may change with respect to the macro GLM_FORCE_QUAT_DATA_WXYZ.
• glm/detail/type_quat.inl
  Instead of fixing the constructor to take (T _w, T _x, T _y, T _z) as input, I conditioned the order of the 4 parameters with respect to the macro GLM_FORCE_QUAT_DATA_WXYZ, and use (T _x, T _y, T _z, T _w) as input order when GLM_FORCE_QUAT_DATA_WXYZ is defined.

Testing

With the change proposed in this pull request, the above code example will construct two identical quaternions q1 and q2 as expected.

Notes

• As this commit only changes the constructor of the quaternion struct, the algebraic part of glm should not be affected.
• Although this change may cause code with previous version of glm to break, I think it eases the uses of future glm users. If this commit is considered to be merged, I can add some macro to give an option to keep the old behavior for compatibility reasons.

Thank you for patiently reading through this proposal!

Signed-off-by: Gaoyang Zhang gy@blurgy.xyz

[blurgyy]

I have updated tests to adopt the default constructor of qua proposed in f931c49. e800c41 and f5187c3 is identical, the force push is for clarity of commit history.

[blurgyy]

I have just run ctest to discover this turns out to be a much larger project than I thought. I will not make further commits if this proposal is not in consideration.

[christophe-lunarg]

The idea looks great except that it changed the default behavior which will break application.

Instead of GLM_FORCE_QUAT_DATA_WXYZ, I think you should create a GLM_FORCE_QUAT_DATA_XYZW to enforce your new behavior.

[blurgyy]

Thank you for your advice, this sounds more reasonable.

I have made the following changes:

• 59ddeb7 Use w,x,y,z as default data layout to agree with order of parameters for quat's constructor (removed macro GLM_FORCE_QUAT_DATA_WXYZ)
• 59ddeb7 Define GLM_FORCE_QUAT_DATA_XYZW to enforce x,y,z,w data layout for quat
• de7c83f Renamed related test file (test/core/core_force_quat_wxyz.cpp -> test/core/core_force_quat_xyzw.cpp)

This keeps the constructor's behavior, but still changes the previous behavior of operator[].

Another thing I have noticed is that the test file test/core/core_force_quat_wxyz.cpp (now test/core/core_force_quat_xyzw.cpp) does not test anything, I wonder if it's intended.

[christophe-lunarg]

Thanks for contributing!

[xiaozhuai]

The idea looks great except that it changed the default behavior which will break application.

Instead of GLM_FORCE_QUAT_DATA_WXYZ, I think you should create a GLM_FORCE_QUAT_DATA_XYZW to enforce your new behavior.

@christophe-lunarg @blurgyy
The default data layout is xyzw before 0.9.9.8, and now, the default data layout is wxyz.
If I use the latest commit, then I need to define GLM_FORCE_QUAT_DATA_XYZW to keep the default behavior consistent with 0.9.9.8.
Is this by design?
See also microsoft/vcpkg#34523 and microsoft/vcpkg#32685 (comment)

[christophe-lunarg]

Erm, I agree that the default should be xyzw and that change broke compatibility... :(

[xiaozhuai]

@christophe-lunarg
Thanks for your reply : )
So can we change the default behavior back to xyzw and release a new version as soon as possible?
3 years have passed since the last release of a new version.
The current incompatibility changes were not in the release version.
Perhaps it is time to release a new version and fix the broken compatibility.

[christophe-lunarg]

Problem: C.I. is completely broken and should be upgraded to Github actions otherwise I am not really confident with releasing a new version...

[christophe-lunarg]

But yes I would defintely take a PR to switch the default behavior...

[xiaozhuai]

Problem: C.I. is completely broken and should be upgraded to Github actions otherwise I am not really confident with releasing a new version...

I can help with CI if you like : )

[christophe-lunarg]

That would be huge!

If you look at:

• https://github.com/g-truc/glm/blob/master/.appveyor.yml
• https://github.com/g-truc/glm/blob/master/.travis.yml

You should be able to see the number of combinasions that were tested.

At least a PR with initial github actions setup so that I can see how that works would be huge.

[xiaozhuai]

That would be huge!

I've take a look at these two files. Yes, it is.

I use github actions for my own project too.
https://github.com/xiaozhuai/imageinfo
This repo contains win x86/win x64/linux/macos CI matrix.
I hope that would be helpful.

[christophe-lunarg]

Thanks, I'll have a look!

[marekr]

Problem: C.I. is completely broken and should be upgraded to Github actions otherwise I am not really confident with releasing a new version...

#1145

Someone tried to start a actions MR for this awhile ago

[xiaozhuai]

Hi @christophe-lunarg
Any progress here？

Best wishes.

[gottfriedleibniz]

All commits related to this GLM_FORCE_QUAT_DATA_* change should be reverted to match 0.9.9.8 functionality. Quaternion constructors have been in a broken state for multiple years now.

Otherwise,

I can add some macro to give an option to keep the old behavior for compatibility reasons.

should be implemented.