<p>People always forget that there is no "camera" in OpenGL. In order to simulate a camera you have to move the whole world inversely. So if you want ur camera looking 30 degrees downward, you move the whole world 30 degrees upwards. If you want your camera moved to the left, you move the whole world right. That's why you will notice the <code>"-"</code> sign in the translation vector where he used the variable <code>position</code>. </p>

<p>Hence the reason there is no separate "view" matrix in openGL, it's modelview matrix combined. That's the reason for taking the inverse. Since a view matrix represent's the camera's forward, up and side, you have to take the inverse since the orientation is defined for the world not the camera.</p>

CC BY-SA 3.0
2017-09-06T16:02:37.553Z
The code make a lot of sense now that I've read your answer. I had a hunch that this is it but couldn't quite figure it out. Thank you!

While looking into the issue I have also stumbled across this article that explains in greater detail what you wrote: https://www.3dgep.com/understanding-the-view-matrix/. Maybe someone else will find it useful as well.
Mihai Bişog
CC BY-SA 3.0
2017-09-06T09:55:25.500Z
2017-09-06T09:55:25.500Z
gallickgunner
<p>First of all, you talk about inverse orientation of points in matrix, this is needed because the subtraction logic in world transformations are directly relationed with screen rotation, instead it that the camera moviments (translation you mentioned) no are directly relationed of the screen position around center of projection.</p>

CC BY-SA 4.0
2020-01-28T18:07:51.260Z
2020-01-28T18:07:51.260Z
Leonardo Fortes
<p>I've been going over some OpenGL learning resources and one of them is this article: <a href="https://www.tomdalling.com/blog/modern-opengl/04-cameras-vectors-and-input/" rel="noreferrer">Modern OpenGL 04 - Cameras, Vectors &amp; Input</a> in which the author presents an approach to building a <code>Camera</code> class that can be used to derive the view and projection matrices.</p>

<p>In the accompanying source code there is a function that returns the orientation of the camera as a transform matrix (<a href="https://github.com/tomdalling/opengl-series/blob/2f1cb93a531f4f9bd5cbad5b2ac1ebe0cfcff7c7/source/04_camera/source/tdogl/Camera.cpp#L74-L79" rel="noreferrer">permalink to source code</a>) which is implemented like this:</p>

<pre><code>glm::mat4 Camera::orientation() const {
    glm::mat4 orientation;
    orientation = glm::rotate(orientation, glm::radians(_verticalAngle), glm::vec3(1,0,0));
    orientation = glm::rotate(orientation, glm::radians(_horizontalAngle), glm::vec3(0,1,0));
    return orientation;
}
</code></pre>

<p>If I'd like to translate the camera relative to the direction it is facing then I would assume that I could multiply the orientation matrix by the translation vector to get a new vector that does the translation in the direction the camera is facing.</p>

<p>However, this does not yield the result I was expecting. After looking at how the forward, up and right axis are derived (<a href="https://github.com/tomdalling/opengl-series/blob/2f1cb93a531f4f9bd5cbad5b2ac1ebe0cfcff7c7/source/04_camera/source/tdogl/Camera.cpp#L104-L117" rel="noreferrer">permalink to source code</a>):</p>

<pre><code>glm::vec3 Camera::forward() const {
    glm::vec4 forward = glm::inverse(orientation()) * glm::vec4(0,0,-1,1);
    return glm::vec3(forward);
}

glm::vec3 Camera::right() const {
    glm::vec4 right = glm::inverse(orientation()) * glm::vec4(1,0,0,1);
    return glm::vec3(right);
}

glm::vec3 Camera::up() const {
    glm::vec4 up = glm::inverse(orientation()) * glm::vec4(0,1,0,1);
    return glm::vec3(up);
}
</code></pre>

<p>I can see that I need to multiply the translation vector with the inverse of the orientation matrix to get the expected result but I don't understand why. Isn't the orientation (as used in this article) a rotation matrix? If that's the case then why do I need to inverse it?</p>

CC BY-SA 3.0
2017-09-05T17:02:46.930Z
I guess the author actually computes *inverse* orientation in `orientation` because he calls this `orientation` in `Camera::view` and then `Camera::matrix` without transpose or inversion of it. And because `glfwGetCursorPos` will give you flipped Y coordinates, the `orientation` does compute the inverse of orientation coincidentally. However X coordinates are not flipped, which should cause problem but I cannot explain why it does not.
TheBusyTypist
<opengl><3d><transformations>
Why do I need to inverse the orientation matrix of a camera to be able to translate it in the direction it is facing?
Mihai Bişog
# Why do I need to inverse the orientation matrix of a camera to be able to translate it in the direction it is facing?

(Asked by: username_0 on 2017-09-05)

I've been going over some OpenGL learning resources and one of them is this article: [Modern OpenGL 04 - Cameras, Vectors & Input](https://www.tomdalling.com/blog/modern-opengl/04-cameras-vectors-and-input/) in which the author presents an approach to building a `Camera` class that can be used to derive the view and projection matrices.

In the accompanying source code there is a function that returns the orientation of the camera as a transform matrix ([permalink to source code](https://github.com/tomdalling/opengl-series/blob/2f1cb93a531f4f9bd5cbad5b2ac1ebe0cfcff7c7/source/04_camera/source/tdogl/Camera.cpp#L74-L79)) which is implemented like this:

```
glm::mat4 Camera::orientation() const {
    glm::mat4 orientation;
    orientation = glm::rotate(orientation, glm::radians(_verticalAngle), glm::vec3(1,0,0));
    orientation = glm::rotate(orientation, glm::radians(_horizontalAngle), glm::vec3(0,1,0));
    return orientation;
}

```

If I'd like to translate the camera relative to the direction it is facing then I would assume that I could multiply the orientation matrix by the translation vector to get a new vector that does the translation in the direction the camera is facing.

However, this does not yield the result I was expecting. After looking at how the forward, up and right axis are derived ([permalink to source code](https://github.com/tomdalling/opengl-series/blob/2f1cb93a531f4f9bd5cbad5b2ac1ebe0cfcff7c7/source/04_camera/source/tdogl/Camera.cpp#L104-L117)):

```
glm::vec3 Camera::forward() const {
    glm::vec4 forward = glm::inverse(orientation()) * glm::vec4(0,0,-1,1);
    return glm::vec3(forward);
}

glm::vec3 Camera::right() const {
    glm::vec4 right = glm::inverse(orientation()) * glm::vec4(1,0,0,1);
    return glm::vec3(right);
}

glm::vec3 Camera::up() const {
    glm::vec4 up = glm::inverse(orientation()) * glm::vec4(0,1,0,1);
    return glm::vec3(up);
}

```

I can see that I need to multiply the translation vector with the inverse of the orientation matrix to get the expected result but I don't understand why. Isn't the orientation (as used in this article) a rotation matrix? If that's the case then why do I need to inverse it?

**Tags:** opengl, 3d, transformations

> **Comments:**
> **username_1**: I guess the author actually computes *inverse* orientation in `orientation` because he calls this `orientation` in `Camera::view` and then `Camera::matrix` without transpose or inversion of it. And because `glfwGetCursorPos` will give you flipped Y coordinates, the `orientation` does compute the inverse of orientation coincidentally. However X coordinates are not flipped, which should cause problem but I cannot explain why it does not.  

---

## 2 answers

### Answer by username_2 on 2017-09-06. Score: 8 | Accepted answer

People always forget that there is no "camera" in OpenGL. In order to simulate a camera you have to move the whole world inversely. So if you want ur camera looking 30 degrees downward, you move the whole world 30 degrees upwards. If you want your camera moved to the left, you move the whole world right. That's why you will notice the `"-"` sign in the translation vector where he used the variable `position`.

Hence the reason there is no separate "view" matrix in openGL, it's modelview matrix combined. That's the reason for taking the inverse. Since a view matrix represent's the camera's forward, up and side, you have to take the inverse since the orientation is defined for the world not the camera.

> **Comments:**
> **username_0**: The code make a lot of sense now that I've read your answer. I had a hunch that this is it but couldn't quite figure it out. Thank you!  While looking into the issue I have also stumbled across this article that explains in greater detail what you wrote: https://www.3dgep.com/understanding-the-view-matrix/. Maybe someone else will find it useful as well.  

---

### Answer by username_3 on 2020-01-28. Score: 0

First of all, you talk about inverse orientation of points in matrix, this is needed because the subtraction logic in world transformations are directly relationed with screen rotation, instead it that the camera moviments (translation you mentioned) no are directly relationed of the screen position around center of projection.


---

