Can't create a quat from euler angles with yaw above 90 glm

Here's some background: I'm working on a game engine and I've recently added a physics engine (physx in this case ). problem is that my transform class uses euler angles for rotation and the physics engine's transform class uses euler angles. so I just implemented a method to change my transform class to the physics engine transform and back. It's working well but I've discovered a weird bug.

Behavior I get:

When the Yaw(second element of the euler vector) of the rotation is above 90 degrees it doesn't make the object rotate anymore on the y axis and start's messing around with the pitch and the roll (weird shaking skip from 0 to 180 and back a lot). The debugging tools shows that the rotation doesn't go above 91 but does go to about 90.0003 max I do transfer the degrees to radians. Example: To show this bug I have a cube with a python script rotating it :

from TOEngine import * 

class rotate:
    direction = vec3(0,10,0)
    def Start(self):
        pass
    def Update(self,deltaTime):
        transform.Rotate(self.direction*deltaTime*5)       
        pass

Engine itself written in cpp but I got a scripting system working with embedded python. TOEngine is just my module and the script itself is just rotating the cube every frame. The cube start at 0 , 0 , 0 rotation and rotating fine but stops and 90 degress yaw and starts shaking.

This only happens when the physics system is enabled so I know that the bug must be in the method transferring the rotation from euler to quat and back every frame using glm.

Here's the actual problematic code :

void RigidBody::SetTransform(Transform transform)
{
    glm::vec3 axis = transform.rotation;
    rigidbody->setGlobalPose(PxTransform(*(PxVec3*)&transform.position,*(PxQuat*)&glm::quat(glm::radians(transform.rotation))));//Attention Over Here
}

Transform RigidBody::GetTransform()
{
    auto t = rigidbody->getGlobalPose();
    return Transform(*(glm::vec3*)&t.p, glm::degrees(glm::eulerAngles(*(glm::quat*)&t.q)), entity->transform.scale);
}

Avoid the weird type punning PxQuat is basically the same as glm::quat and PxVec3 is basically the same as glm::vec3. I expect this code to transfer between the physics's engine transform class and my transform class by changing the rotation from euler angles degress to a quat with radians(the hard part).

And the inside the physics system:

void PreUpdate(float deltaTime)override {   //Set Physics simulation changes to the scene
mScene->fetchResults(true);
for (auto entity : Events::scene->entities)
    for (auto component : entity->components)
        if (component->GetName() == "RigidBody")
            entity->transform = ((RigidBody*)component)->GetTransform();    //This is running on the cube entity
}
void PostUpdate(float deltaTime)override {  //Set Scene changes To Physics simulation
for (auto entity : Events::scene->entities)
    for (auto component : entity->components)
        if (component->GetName() == "RigidBody")
            ((RigidBody*)component)->SetTransform(entity->transform);//This is running on the cube entity
mScene->simulate(deltaTime);
}

PreUpdate runs before the update every frame PostUpdate runs after the update every frame. the method Update(showed in the script above) as the name suggests runs on the update...(in between PreUpdate and PostUpdate). The cube has a rigidbody component. What I expect getting: a rotating cube that doesn't stop rotating when it reaches yaw 90 degrees.

I know this one is a bit complex. I tried my best to explain the bug I believe the problem is in changing Euler angles to a quat.

Solution

Regarding the conversion from PxQuat to glm::quat, do read the documentation at https://en.cppreference.com/w/cpp/language/explicit_cast and https://en.cppreference.com/w/cpp/language/reinterpret_cast and look for undefined behavior in the page on reinterpret_cast. As far as I can tell, that c-style cast is not guaranteed to work, or even desirable. While I am digressing at this point, but remember that you have two options for this conversion.

glm::quat glmQuat = GenerateQuat();
physx::PxQuat someQuat = *(physx::PxQuat*)(&glmQuat); //< (1)
physx::PxQuat someOtherQuat = ConvertGlmQuatToPxQuat(glmQuat); //< (2)

(1) This option has potential to result in undefined behavior but more importantly, you did not save a copy. That statement is certain to result in 1 copy constructor invocation.

(2) This option, on account of return value optimization, will also result in a single construction of physx::PxQuat.

So in effect, by taking option (1), you do not save any cost but are risking undefined behavior. With option (2), cost is the same but code is now standards compliant. Now back to the original point.

I would ordinarily do everything in my capacity to avoid using euler angles as they are error prone and far more confusing than quaternions. That said here is a simple test you can set up to test your quaternion conversion from euler angles (keep physx out of this for the time being).

You need to generate the following methods.

glm::mat3 CreateRotationMatrix(glm::vec3 rotationDegrees);
glm::mat3 CreateRotationMatrix(glm::quat inputQuat);
glm::quat ConvertEulerAnglesToQuat(glm::vec3 rotationDegrees);

and then your pseudo code for the test looks like below.

for (auto angles : allPossibleAngleCombinations) {
    auto expectedRotationMatrix = CreateRotationMatrix(angles);
    auto convertedQuat = ConvertEulerAnglesToQuat(angles);
    auto actualRotationMatrix = CreateRotationMatrix(convertedQuat);
    ASSERT(expectedRotationMatrix, actualRotationMatrix);
}

Only if this test passes for you, can you then look at the next problem of converting them to PxQuat. I would guess that this test is going to fail for you. The one advice I would give is that one of the input angles, (depends on convention) needs to be range limited. Say, if you keep your yaw angle limited between -90, 90 degrees, chances are your test might succeed. This is because, there are a non-unique combination of euler angles that can result in the same rotation matrix.