4
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Looks fine to me. Is anything not working as it should, or do you have any specific questions about the code or Euler angles? Asking for "your opinion about this approach" is very vague and will probably lead to questions like this being closed on this site. $\endgroup$ – Nathan Reed Apr 10 '16 at 19:45
  • 1
    $\begingroup$ Thanks @NathanReed for your reply and reviewing my code. You were right about the 'open endedness' of the question, thus, rephrased it. $\endgroup$ – Sayan Pal Apr 10 '16 at 20:40
  • 1
    $\begingroup$ Meta discussion about review questions. $\endgroup$ – Martin Ender Apr 11 '16 at 7:04
4
$\begingroup$

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.

$\endgroup$
  • 3
    $\begingroup$ I would just add that Euler angles work very well for FPS-style or orbiting cameras, where you can only rotate on 2 axes, and controls map directly to the yaw and pitch angles. There are no gimbal lock problems then. If your camera can rotate on all 3 axes, then quaternions may make more sense. $\endgroup$ – Nathan Reed Apr 13 '16 at 6:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.