8000 Fix quaternion orientation in `glm::decompose` by bosmacs · Pull Request #1012 · g-truc/glm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix quaternion orientation in glm::decompose #1012

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 21, 2020

Conversation

bosmacs
Copy link
@bosmacs bosmacs commented May 11, 2020

Between 0.9.8 and 0.9.9 a change to the implementation of decompose caused the conjugate of the rotation quaternion to be returned. This has also been noted in this Stack Overflow question, in particular this comment. This seems like a regression that ought to be fixed to avoid having to conjugate the result of decompose in the future.

@christophe-lunarg christophe-lunarg merged commit 1cf91a1 into g-truc:master Nov 21, 2020
@christophe-lunarg
Copy link

Thanks for contributing!

@christophe-lunarg christophe-lunarg added this to the GLM 0.9.9 milestone Nov 21, 2020
@christophe-lunarg christophe-lunarg self-assigned this Nov 21, 2020
@thekend
Copy link
thekend commented Feb 20, 2021

I think something is wrong with this "fix". Let's say we have a quat Q. Let M = mat4_cast(Q) and let Q2 be the quaternion resulted by decomposing M. We should get the same results with transforming a vec3 by Q, M and Q2. However, it's not the case. It seems that transforming with Q and M are results the same vector but with Q2 we get different result.

`

vec3 transformVec(const mat4& m, const vec3& v)
{
    vec4 vh(v.x, v.y, v.z, 1.0f);
    vh = m * vh;
    return { vh.x / vh.w, vh.y / vh.w, vh.z / vh.w };
}

void testDecompose()
{
    constexpr const vec3 vI = { 1.0f, 0.0f, 0.0f };
    constexpr const vec3 vJ = { 0.0f, 1.0f, 0.0f };
    constexpr const vec3 vK = { 0.0f, 0.0f, 1.0f };

    quat rotQ = angleAxis(radians(45.0f), vec3(0.0f, 1.0f, 0.0f));

    vec3 xQ = rotQ * vI;
    vec3 yQ = rotQ * vJ;
    vec3 zQ = rotQ * vK;

    mat4 rotM = mat4_cast(rotQ);

    vec3 xM = transformVec(rotM, vI);
    vec3 yM = transformVec(rotM, vJ);
    vec3 zM = transformVec(rotM, vK);

    vec3 scale;
    quat rotQ2;
    vec3 trans;
    vec3 skew;
    vec4 proj;
    decompose(rotM, scale, rotQ2, trans, skew, proj);

    vec3 xQ2 = rotQ2 * vI;
    vec3 yQ2 = rotQ2 * vJ;
    vec3 zQ2 = rotQ2 * vK;
}

`

xQ = {0.707106709, 0.00000000, -0.707106829}
xM = {0.707106709, 0.00000000, -0.707106829}
xQ2 = {0.707106709, 0.00000000, 0.707106829}

@stephomi
Copy link
stephomi commented Mar 5, 2021

I Agree, I'm still using the version before the fix as it was working perfectly for my use case.
I only decompose matrices with translation, rotation and scale (non-uniform), but I can't speak for skew/persp.

I don't get all the comments about conjugate in the stackoverflow thread though, maybe it was a side effect somewhere else that has been fixed since?

I would expect a simple decompose/recompose operation to always fall back on the initial matrix, like before:

glm::vec3 scale, trans, skew;
glm::vec4 persp;
glm::quat rot;
bool success = glm::decompose(matrix, scale, rot, trans, skew, persp);

// matrix ~= success
glm::mat4 recompose = glm::translate(trans) * glm::mat4(rot) * glm::scale(scale);

@thekend
Copy link
thekend commented Mar 6, 2021

Yes, I used this function before and it worked well. Now it's wrong and because I also used it only for matrices composed of scales, rotations and translations, now I use my own simpler decomposeAffineMatrix which decomposes to scale, translation and 3x3 rotation mat and then use glm::quat_cast which seems also working well.

@christophe-lunarg
Copy link

Do you think we should revert ?
#1061 ?

@bosmacs
Copy link
Author
bosmacs commented Mar 6, 2021

I think I've convinced myself that it ought to be reverted. I think the confusion on my (and stack overflow's) part may stem from the column-major indexing of GLSL/glm. In particular, the way Row[i] is constructed, won't it actually contain the ith column of the input matrix? So the way the math is usually written has to be transposed, as it was before.

christophe-lunarg added a commit that referenced this pull request Mar 7, 2021
Revert "Fix quaternion orientation in `glm::decompose`" #1061 #1012
@perkele1989 perkele1989 mentioned this pull request Apr 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0