<blockquote>
<p>Is there a general rule with regard to using the inverse of the “camera” to world when using a homogeneous transform matrix?</p>
</blockquote>
<p>No, there is no general rule. You should always think about which approach is the best one for your specific use-case.</p>
<blockquote>
<p>Nothing else is ever done with the local-to-world matrix - other than taking its inverse. So I'm wondering if it would be easier just to define the world-to-local matrix directly?</p>
</blockquote>
<p>Don't forget, that the source you linked is a tutorial. It has a limited scope and avoids confusing the reader with additional information he might not understand at the time of reading. That said, if I have an isolated look at the rendering process, I can't think of a reason why you absolutely need the cam-to-world matrix there because you want to transform everything into camera space before continuing with other transformations (projection, clipping, etc.). Even though it seems to make no sense to transform something out of camera space just to transform it back later, there still might be some reasons to do exactly this. For example, if some renderable object is attached to the camera coordinate system. Using an extra shader or a branch statement just for objects defined in the camera system usually costs you much more performance than two obsolete transformations.</p>
<p>If we now consider other operations, not just rendering, you might find some useful applications of the camera to world matrix, for example, the movement of a camera that always moves into view direction or orthogonal to it (free camera mode in an FPS). The target point of the movement can be easily determined in camera space. It is just a vector of the movement speeds in each principle direction. Use the camera to world matrix to transform the target point into world space and you have your new location (if no collisions occur).</p>
<p>Lastly, another reason to take the &quot;inverse-route&quot; might be that it is just easier, less work, or more convenient. All objects, including the camera, usually have a world space coordinate and orientation. The transformation to world space is always the same series of operations. Scale-rotate-translate. Since it so common and frequently used, you probably have an optimized function that does not multiply 3 individual matrices but calculates all the entries of the resulting matrix directly. You can still do the same for the world-to-local transformation, but it is less frequently used and if you only need it for your world-to-camera transformation it might be just easier to calculate the inverse since every linear algebra library you might use should provide this function. If you do this not too frequently each frame, it shouldn't affect performance in any notable way.</p>
<p>As I said in the beginning, you should always focus on what your program needs. If you have no use for the camera-to-world matrix other than to calculate the world-to-camera matrix, you can definitely skip this and calculate the world-to-camera matrix directly. Just ask yourself, if it is worth it to add some extra lines of code for that.</p>

CC BY-SA 4.0
2020-06-18T08:35:54.090Z
2020-06-18T08:35:54.090Z
wychmaster
<p>Not sure if this is just specific to <a href="https://www.scratchapixel.com/lessons/3d-basic-rendering/computing-pixel-coordinates-of-3d-point/mathematics-computing-2d-coordinates-of-3d-points" rel="nofollow noreferrer">this article</a> but it says:</p>
<blockquote>
<p>We learned how to convert points from world to any local coordinate
system. If we know the local-to-world matrix, we can multiply the
world coordinate of the point by the inverse of the local-to-world
matrix (the world-to-local matrix).</p>
</blockquote>
<p>Nothing else is ever done with the local-to-world matrix - other than taking its inverse. So I'm wondering if it would be easier just to define the world-to-local matrix directly? Does taking the inverse make things like &quot;moving&quot; the camera more intuitive?</p>
<p>Thanks</p>

<perspective><render>
Is there a general rule with regard to using the inverse of the "camera" to world when using a homogeneous transform matrix?
brent
# Is there a general rule with regard to using the inverse of the "camera" to world when using a homogeneous transform matrix?

(Asked by: username_0 on 2020-06-17)

Not sure if this is just specific to [this article](https://www.scratchapixel.com/lessons/3d-basic-rendering/computing-pixel-coordinates-of-3d-point/mathematics-computing-2d-coordinates-of-3d-points) but it says:

> We learned how to convert points from world to any local coordinate
> system. If we know the local-to-world matrix, we can multiply the
> world coordinate of the point by the inverse of the local-to-world
> matrix (the world-to-local matrix).

Nothing else is ever done with the local-to-world matrix - other than taking its inverse. So I'm wondering if it would be easier just to define the world-to-local matrix directly? Does taking the inverse make things like "moving" the camera more intuitive?

Thanks

**Tags:** perspective, render


---

## 1 answers

### Answer by username_1 on 2020-06-18. Score: 0 | Accepted answer

> Is there a general rule with regard to using the inverse of the “camera” to world when using a homogeneous transform matrix?

No, there is no general rule. You should always think about which approach is the best one for your specific use-case.

> Nothing else is ever done with the local-to-world matrix - other than taking its inverse. So I'm wondering if it would be easier just to define the world-to-local matrix directly?

Don't forget, that the source you linked is a tutorial. It has a limited scope and avoids confusing the reader with additional information he might not understand at the time of reading. That said, if I have an isolated look at the rendering process, I can't think of a reason why you absolutely need the cam-to-world matrix there because you want to transform everything into camera space before continuing with other transformations (projection, clipping, etc.). Even though it seems to make no sense to transform something out of camera space just to transform it back later, there still might be some reasons to do exactly this. For example, if some renderable object is attached to the camera coordinate system. Using an extra shader or a branch statement just for objects defined in the camera system usually costs you much more performance than two obsolete transformations.

If we now consider other operations, not just rendering, you might find some useful applications of the camera to world matrix, for example, the movement of a camera that always moves into view direction or orthogonal to it (free camera mode in an FPS). The target point of the movement can be easily determined in camera space. It is just a vector of the movement speeds in each principle direction. Use the camera to world matrix to transform the target point into world space and you have your new location (if no collisions occur).

Lastly, another reason to take the "inverse-route" might be that it is just easier, less work, or more convenient. All objects, including the camera, usually have a world space coordinate and orientation. The transformation to world space is always the same series of operations. Scale-rotate-translate. Since it so common and frequently used, you probably have an optimized function that does not multiply 3 individual matrices but calculates all the entries of the resulting matrix directly. You can still do the same for the world-to-local transformation, but it is less frequently used and if you only need it for your world-to-camera transformation it might be just easier to calculate the inverse since every linear algebra library you might use should provide this function. If you do this not too frequently each frame, it shouldn't affect performance in any notable way.

As I said in the beginning, you should always focus on what your program needs. If you have no use for the camera-to-world matrix other than to calculate the world-to-camera matrix, you can definitely skip this and calculate the world-to-camera matrix directly. Just ask yourself, if it is worth it to add some extra lines of code for that.


---

