<p><strong>World coordinates</strong> are at the bedrock of your game world. The 3D positions of all objects are ultimately specified in world space, either directly or through a node hierarchy. The ground, buildings, trees, and other stationary things will be fixed in world space. Gameplay calculations and physics will be done in world space (perhaps with some local recentering for precision purposes, if the world is large). The axes of world coordinates are often taken to represent compass directions, such as X = east, Y = north, Z = up.</p>

<p><strong>Local coordinates</strong> are attached to an object (there is one local coordinate space for each object). The axes may represent something meaningful to the object, for instance X = forward, Y = left, Z = up for an object such as a character, vehicle, gun, etc. that has an inherent orientation. As the object moves around, the relationship between local and world space (as expressed by a transformation matrix) will change. For instance if you flip your car upside down, its local Z axis ("up" in local space) will now be pointing "down" in world space.</p>

<p><strong>Camera or view coordinates</strong> are local coordinates attached to the camera. This is still a 3D coordinate system, without any projection or anything, but with the axes aligned to match the screen orientation: usually X = right, Y = up, Z = backward. The transformation from world to view space is often known as the "view matrix".</p>

<p><strong>Clip space coordinates</strong> are the coordinates output by a vertex shader: coordinates to which the projection matrix has been applied, but not the perspective divide. This is a 4D (homogeneous) space. (World, local, and view space are 3D with an implicit w = 1.) It's so named because this is the space in which view frustum clipping and culling takes place (conceptually, at least).</p>

<p><strong>Normalized device coordinates</strong>, also commonly known as "screen space" although that term is a little loose, are what you get after applying the perspective divide to clip space coordinates. The 3D coordinates now represent the 2D positions of points on screen, with X and Y in [−1, 1], together with the depth within the depth buffer range, Z in [0, 1] for D3D or [−1, 1] for OpenGL. The axis orientation is X = right, Y = up, and Z can be either forward or backward depending on the depth buffer configuration.</p>

<p><strong>Device coordinates</strong> are 2D pixel coordinates within the render target, with (0, 0) in the upper-left corner, X = right, Y = down. One arrives at device coordinates by applying the viewport transform to the normalized device coordinates; the viewport controls at what pixel offset and resolution the image appears in the render target. One thing that's important to note is that device coordinates are not integer values; they aren't indices of pixels. They're a continuous 2D coordinate system, using pixel-sized units, but in which fractional (subpixel) values are perfectly valid. Pixel centers lie at 0.5 offsets (like 0.5, 1.5, 2.5, ...) in this coordinate system.</p>

CC BY-SA 4.0
2020-11-13T14:58:28.410Z
Great answer! Would you mind clarifying [in the answer] how widespread the use of these terms is, - are they used in the industry, do they have the same meaning in most books? I think that would help a lot (me at least).
Evgenia Karunus
CC BY-SA 3.0
2015-12-02T22:27:09.273Z
2015-12-02T22:27:09.273Z
Nathan Reed
<p>Can I get to know the difference between the three? A good example would add up too.</p>

<3d><2d>
World coordinates, Normalised device coordinates and device coordinates
Anish Sharma
# World coordinates, Normalised device coordinates and device coordinates

(Asked by: username_0 on 2015-12-02)

Can I get to know the difference between the three? A good example would add up too.

**Tags:** 3d, 2d


---

## 1 answers

### Answer by username_1 on 2015-12-02. Score: 29 | Accepted answer

**World coordinates** are at the bedrock of your game world. The 3D positions of all objects are ultimately specified in world space, either directly or through a node hierarchy. The ground, buildings, trees, and other stationary things will be fixed in world space. Gameplay calculations and physics will be done in world space (perhaps with some local recentering for precision purposes, if the world is large). The axes of world coordinates are often taken to represent compass directions, such as X = east, Y = north, Z = up.

**Local coordinates** are attached to an object (there is one local coordinate space for each object). The axes may represent something meaningful to the object, for instance X = forward, Y = left, Z = up for an object such as a character, vehicle, gun, etc. that has an inherent orientation. As the object moves around, the relationship between local and world space (as expressed by a transformation matrix) will change. For instance if you flip your car upside down, its local Z axis ("up" in local space) will now be pointing "down" in world space.

**Camera or view coordinates** are local coordinates attached to the camera. This is still a 3D coordinate system, without any projection or anything, but with the axes aligned to match the screen orientation: usually X = right, Y = up, Z = backward. The transformation from world to view space is often known as the "view matrix".

**Clip space coordinates** are the coordinates output by a vertex shader: coordinates to which the projection matrix has been applied, but not the perspective divide. This is a 4D (homogeneous) space. (World, local, and view space are 3D with an implicit w = 1.) It's so named because this is the space in which view frustum clipping and culling takes place (conceptually, at least).

**Normalized device coordinates**, also commonly known as "screen space" although that term is a little loose, are what you get after applying the perspective divide to clip space coordinates. The 3D coordinates now represent the 2D positions of points on screen, with X and Y in [−1, 1], together with the depth within the depth buffer range, Z in [0, 1] for D3D or [−1, 1] for OpenGL. The axis orientation is X = right, Y = up, and Z can be either forward or backward depending on the depth buffer configuration.

**Device coordinates** are 2D pixel coordinates within the render target, with (0, 0) in the upper-left corner, X = right, Y = down. One arrives at device coordinates by applying the viewport transform to the normalized device coordinates; the viewport controls at what pixel offset and resolution the image appears in the render target. One thing that's important to note is that device coordinates are not integer values; they aren't indices of pixels. They're a continuous 2D coordinate system, using pixel-sized units, but in which fractional (subpixel) values are perfectly valid. Pixel centers lie at 0.5 offsets (like 0.5, 1.5, 2.5, ...) in this coordinate system.

> **Comments:**
> **username_2**: Great answer! Would you mind clarifying [in the answer] how widespread the use of these terms is, - are they used in the industry, do they have the same meaning in most books? I think that would help a lot (me at least).  

---

