<p>I assume the term <em>object description</em> refers to the set of 3D vertices a mesh is made of. And I also assume <em>reference frame</em> actually means <em>coordinate space</em>. For a book on computer graphics, it sure uses some very uncommon words. </p>

<p>In computer graphics, we often have to transform a set of vertices from one coordinate space to another. For example, an artist may have modelled a rubber ducky, aligned in such a way that it looks down the positive x-axis and it uses centimeters for its units. </p>

<p>When we place the ducky in our world (let's say it uses <em>meters</em> as the primary unit), we scale, rotate and translate it so that it neatly floats on the water in a bath tub.</p>

<p>Then we have our camera, which can move freely around in our scene with its own translation and rotation parameters. And finally there is the notion of <em>projection</em>, which takes into account the field of view and the aspect ratio of our frame to project the 3D point onto a 2D image.</p>

<p>Our job is to calculate exactly where in our 2D image the 3D vertex ends up, if at all. And for this, we will have to go through the sequence of all our coordinate spaces: from object to world to camera (a.k.a. view) to projection.</p>

<p>So that's how most graphics programmers visualise this process and hence why the book also follows this sequence: it takes the object and follows it through its transformations until it ends up in our 2D image.</p>

<p>It seems you prefer it the other way around: you take the camera as a fixed object and rotate the world around it. But you have to admit this isn't very logical, as the camera sure isn't fixed and the world does not revolve around it.</p>

CC BY-SA 4.0
2018-11-13T06:36:29.003Z
@Paul Houx, see https://www.youtube.com/playlist?list=PLzH6n4zXuckrPkEUK5iMQrQyvj9Z6WCrm in this he talks  about fixing the camera
mathmaniage
CC BY-SA 4.0
2018-11-16T16:02:21.413Z
Alright, point taken about the "frame of reference". Fact remains that, in OpenGL at least, a *model matrix* converts from object to world space, a *view matrix* from world to camera space and a *projection matrix* from camera to clip space. Only if you want to go the other way around should you first take its inverse.
Paul Houx
CC BY-SA 4.0
2018-11-12T11:06:11.270Z
2018-11-12T11:06:11.270Z
Paul Houx
<p>My book says:</p>

<blockquote>
  <p>After a scene has been constructed we transfer object descriptions to the viewing-coordinate reference frame. This conversion of object descriptions is equivalent to a sequence of transformations that superimposes the viewing reference frame onto the world frame, so we translate  the  view reference frame onto the origin and  rotate by an angle to align the view to the world.</p>
</blockquote>

<p>So, my confusion is: if we're transferring object descriptions from the world to view, shouldn't we superimpose the world onto the view,   and hence take the inverse  of  the above transformation? Why is my book saying things the other way around?</p>

<3d>
3D scene construction and change of coordinates
mathmaniage
# 3D scene construction and change of coordinates

(Asked by: username_0 on 2018-11-08)

My book says:

> After a scene has been constructed we transfer object descriptions to the viewing-coordinate reference frame. This conversion of object descriptions is equivalent to a sequence of transformations that superimposes the viewing reference frame onto the world frame, so we translate the view reference frame onto the origin and rotate by an angle to align the view to the world.

So, my confusion is: if we're transferring object descriptions from the world to view, shouldn't we superimpose the world onto the view, and hence take the inverse of the above transformation? Why is my book saying things the other way around?

**Tags:** 3d


---

## 1 answers

### Answer by username_1 on 2018-11-12. Score: 2

I assume the term *object description* refers to the set of 3D vertices a mesh is made of. And I also assume *reference frame* actually means *coordinate space*. For a book on computer graphics, it sure uses some very uncommon words.

In computer graphics, we often have to transform a set of vertices from one coordinate space to another. For example, an artist may have modelled a rubber ducky, aligned in such a way that it looks down the positive x-axis and it uses centimeters for its units.

When we place the ducky in our world (let's say it uses *meters* as the primary unit), we scale, rotate and translate it so that it neatly floats on the water in a bath tub.

Then we have our camera, which can move freely around in our scene with its own translation and rotation parameters. And finally there is the notion of *projection*, which takes into account the field of view and the aspect ratio of our frame to project the 3D point onto a 2D image.

Our job is to calculate exactly where in our 2D image the 3D vertex ends up, if at all. And for this, we will have to go through the sequence of all our coordinate spaces: from object to world to camera (a.k.a. view) to projection.

So that's how most graphics programmers visualise this process and hence why the book also follows this sequence: it takes the object and follows it through its transformations until it ends up in our 2D image.

It seems you prefer it the other way around: you take the camera as a fixed object and rotate the world around it. But you have to admit this isn't very logical, as the camera sure isn't fixed and the world does not revolve around it.

> **Comments:**
> **username_0**: @username_1, see https://www.youtube.com/playlist?list=PLzH6n4zXuckrPkEUK5iMQrQyvj9Z6WCrm in this he talks  about fixing the camera  
> **username_1**: Alright, point taken about the "frame of reference". Fact remains that, in OpenGL at least, a *model matrix* converts from object to world space, a *view matrix* from world to camera space and a *projection matrix* from camera to clip space. Only if you want to go the other way around should you first take its inverse.  

---

