Computing camera front direction from Euler angles

Question

I am new to OpenGL and Computer Graphics in general.

Lately I was learning how to model a camera, specifically how to model the rotation of camera. I was introduced to Euler angles for this purpose.

I got a rough idea about how to use Euler angles to model camera rotation from this post. Based on that, I wrote something like below:

GLfloat yaw, pitch;
...
void mouse_callback(GLFWwindow* window, double xpos, double ypos)
{
        /* 
           Here I am updating the yaw, and pitch values 
           based on mouse movement and previous mouse position
        */

        glm::mat4 yawPitchRotMat;
        /* We want to do yaw * pitch. */

        //y-axis as yaw axis
        yawPitchRotMat = glm::rotate(yawPitchRotMat, glm::radians(yaw), 
                         glm::vec3(0.0f, 1.0f, 0.0f));

        //x-axis as pitch axis
        yawPitchRotMat = glm::rotate(yawPitchRotMat, glm::radians(pitch), 
                         glm::vec3(1.0f, 0.0f, 0.0f));

        cameraFrontDirection = glm::normalize(-1.0f * 
                 glm::vec3(yawPitchRotMat[2].x, yawPitchRotMat[2].y, yawPitchRotMat[2].z));
}

The above code seems to work. However, I would like to hear your opinion about this approach. Specially as my math is not really very strong, so any mathematical insight regarding Euler angles would be very helpful. Also appreciate any reference to online resource on the same, that is easy to understand.

Note: Though later I also came to know about certain limitation of modelling rotation using Euler angles and use quaternions instead. However I would like to save that topic for future discussion, as I am yet to read about that in details.

Answer 1

This kind of navigation works well for situations that are centered about objects. It keeps the up vector always pointing upward which makes it less possible for confusion.

Bringing quaternions into this mix is not necessarily a good idea. People often totally exaggerate the problems of Euler angles (or taint Tait–Bryan angles). Its true that Euler did not even consider the implications in interpolating the angles. True you can get into big problems if you rotate angles into certain positions and interpolate angle by angle. But this didn't bother Euler so much as he did mathematical modeling where the problem cancels itself out.

• So Euler angles are perfectly fine for storing the rotation, also ok in differential rotation. And in case as no gimbal lock can really happen anyway, you get other problems before it. Euler angles are just not good at linear interpolation in a curved space.

In this case there should not be any bigger problems. Euler angles are much easier to understand. Unless you need to interpolate between 2 recorded positions. However this is a no issue as your collection and interpolation dont need to be based on the same model.

Its possible to look at this model in another light, you can think of it as a vector that records camera position in relation to a center as long as you keep the vector equal length you achieve same thing. You can then just form the matrix by multiplying by up vector and then that by front to get new up. This is even easier to interpolate unless you move trough the actual center but again you can keep normalizing the vector to a length.