<p>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.</p>

<p>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.</p>

<ul>
<li>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. </li>
</ul>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2016-04-13T06:06:54.480Z
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.
Nathan Reed
CC BY-SA 3.0
2016-04-12T14:35:32.873Z
2016-04-12T14:35:32.873Z
joojaa
<p>I am new to OpenGL and Computer Graphics in general. </p>

<p>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. </p>

<p>I got a rough idea about how to use Euler angles to model camera rotation from this <a href="https://www.opengl.org/discussion_boards/showthread.php/133072-Camera-Position-Camera-Angle-Camera-Target-Position?p=986100&amp;viewfull=1#post986100" rel="nofollow">post</a>. Based on that, I wrote something like below:</p>

<pre><code>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));
}
</code></pre>

<p>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.</p>

<p><strong>Note:</strong> 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.</p>

CC BY-SA 3.0
2016-04-10T19:45:35.710Z
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.
Nathan Reed
CC BY-SA 3.0
2016-04-10T20:40:28.353Z
Thanks @NathanReed for your reply and reviewing my code. You were right about the 'open endedness' of the question, thus, rephrased it.
Sayan Pal
CC BY-SA 3.0
2016-04-11T07:04:09.383Z
[Meta discussion about review questions.](http://meta.computergraphics.stackexchange.com/q/223/16)
Martin Ender
<opengl><transformations>
Computing camera front direction from Euler angles
Sayan Pal
# Computing camera front direction from Euler angles

(Asked by: username_0 on 2016-04-10)

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](https://www.opengl.org/discussion_boards/showthread.php/133072-Camera-Position-Camera-Angle-Camera-Target-Position?p=986100&viewfull=1#post986100). 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.

**Tags:** opengl, transformations

> **Comments:**
> **username_1**: 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.  
> **username_0**: Thanks @username_1 for your reply and reviewing my code. You were right about the 'open endedness' of the question, thus, rephrased it.  
> **username_2**: [Meta discussion about review questions.](http://meta.computergraphics.stackexchange.com/q/223/16)  

---

## 1 answers

### Answer by username_3 on 2016-04-12. Score: 4

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.

> **Comments:**
> **username_1**: 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.  

---

