A number of vector spaces are discussed below and widely used in 3D graphics to place objects in a common scene. Transformation [matrices](/9/rendering/matrices/) both define and transform [vectors](/10/rendering/vectors/) between spaces. Either objects are projected into a discretized image for rasterization or rays are projected from the image into the world for raytracing. See [projection matrix](https://www.heuristic42.com/11/rendering/matrices/projection/).
**Object space** is the name given to the coordinate system that objects, i.e. triangle mesh
vertices, are defined in. Each mesh has its own object space, and the data typically remains
static with animation applied on the fly during vertex processing. Exceptions include deformable
objects and dynamically defined meshes such as isosurfaces. Object space operations (as opposed
to image space, below) commonly refers to the use of triangle data, without specific reference
to the vector space, and can also imply more global operations on all instantiated objects in
world space.
**World space** is the space the scene is constructed in, instantiating objects and placing
them in relation to one another by defining an object-to-world space transformation. These
and other transformations can be efficiently stored in 4 × 4 [homogeneous matrices](https://www.heuristic42.com/9/rendering/matrices/#homogeneous-matrices) and applied
by multiplying vertex coordinates. By pre-multiplying and combining transformations, a vertex
can be transformed to a desired space with a single operation. World space is common to all
instances and provides view-independent relative positions to objects in the scene.
With the scene defined, a viewer is necessary to relate a 2D image to the 3D world. Thus, a
virtual camera model is defined, somewhat implicitly in some cases, and is split into two parts:
a view and projection.
**Eye space**, or camera space, is given by the [camera](/8/rendering/cameras/)’s view, commonly position and direction.
The transformation can be thought of as moving the entire world/scene to provide the viewer
location and rotation, which despite appearances is mathematically inexpensive. This analogy
works for other transforms but may be more intuitive here. Like the previous spaces, eye space
is linear and infinite, with viewing volume bounds or projection yet to be defined.
**Clip space** exists after a projection has been applied and is 4D. A typical projection for a
virtual environment is a perspective projection, which computes intersections between a plane
and lines to each vertex. An alternative interpretation is that the x and y coordinates are
divided by $z$, due to the following normalization, to shrink distant objects in the image. Clip
space defines bounds for a viewing volume, where triangles outside can be discarded and those
intersecting can be clipped. Clipping is particularly necessary for triangles that cross the $w = 0$
plane where points would otherwise cause a division by zero when normalized. Perspective-correct vertex interpolation must be performed in clip space, before normalization.
**Normalized device coordinates** (NDC) are a result of the perspective divide, where
4D homogeneous vectors are normalized, $\mathsf{NDC} = \mathsf{clip}_{xyz}/\mathsf{clip}_w$, after the perspective transformation to clip space. The 3D components of visible points commonly range between -1 and 1. This really depends on the projection matrix. A notable case is a difference in the $z$ range between the projections created by OpenGL and DirectX software. To undo a perspective divide when transforming from NDC to eye space, simply transform by the inverse projection matrix and re-normalize with the same divide, rather than attempt to compute and scale by $w$.
**Image space** linearly scales NDC to the pixel dimensions. For example, $\frac{\mathsf{NDC_{xy}} + 1}{2} \mathsf{resolution}$ This is where rasterization would be performed. Alternatively, points in image space can be projected into 3D rays in world space (from the near to the far clipping planes for example), multiplying by the inverse projection and view matrices for raytracing.
A number of vector spaces are discussed below and widely used in 3D graphics to place objects in a common scene. Transformation [matrices](/9/rendering/matrices/) both define and transform [vectors](/10/rendering/vectors/) between spaces. Either objects are projected into a discretized image for rasterization or rays are projected from the image into the world for raytracing. See [projection matrix](https://www.heuristic42.com/11/rendering/matrices/projection/).
**Object space** is the name given to the coordinate system that objects, i.e. triangle mesh
vertices, are defined in. Each mesh has its own object space, and the data typically remains
static with animation applied on the fly during vertex processing. Exceptions include deformable
objects and dynamically defined meshes such as isosurfaces. Object space operations (as opposed
to image space, below) commonly refers to the use of triangle data, without specific reference
to the vector space, and can also imply more global operations on all instantiated objects in
world space.
**World space** is the space the scene is constructed in, instantiating objects and placing
them in relation to one another by defining an object-to-world space transformation. These
and other transformations can be efficiently stored in 4 × 4 [homogeneous matrices](https://www.heuristic42.com/9/rendering/matrices/#homogeneous-matrices) and applied
by multiplying vertex coordinates. By pre-multiplying and combining transformations, a vertex
can be transformed to a desired space with a single operation. World space is common to all
instances and provides view-independent relative positions to objects in the scene.
With the scene defined, a viewer is necessary to relate a 2D image to the 3D world. Thus, a
virtual camera model is defined, somewhat implicitly in some cases, and is split into two parts:
a view and projection.
**Eye space**, or camera space, is given by the [camera](/8/rendering/cameras/)’s view, commonly position and direction.
The transformation can be thought of as moving the entire world/scene to provide the viewer
location and rotation, which despite appearances is mathematically inexpensive. This analogy
works for other transforms but may be more intuitive here. Like the previous spaces, eye space
is linear and infinite, with viewing volume bounds or projection yet to be defined.
**Clip space** exists after a projection has been applied and is 4D. A typical projection for a
virtual environment is a perspective projection, which computes intersections between a plane
and lines to each vertex. An alternative interpretation is that the x and y coordinates are
divided by $z$, due to the following normalization, to shrink distant objects in the image. Clip
space defines bounds for a viewing volume, where triangles outside can be discarded and those
intersecting can be clipped. Clipping is particularly necessary for triangles that cross the $w = 0$
plane where points would otherwise cause a division by zero when normalized. Perspective-correct vertex interpolation must be performed in clip space, before normalization.
**Normalized device coordinates** (NDC) are a result of the perspective divide, where
4D homogeneous vectors are normalized, $\mathsf{NDC} = \mathsf{clip}_{xyz}/\mathsf{clip}_w$, after the perspective transformation to clip space. The 3D components of visible points commonly range between -1 and 1. This really depends on the projection matrix. A notable case is a difference in the $z$ range between the projections created by OpenGL and DirectX software. To undo a perspective divide when transforming from NDC to eye space, simply transform by the inverse projection matrix and re-normalize with the same divide, rather than attempt to compute and scale by $w$.
**Image space** linearly scales NDC to the pixel dimensions. For example, $\frac{\mathsf{NDC_{xy}} + 1}{2} \mathsf{resolution}$ This is where rasterization would be performed. Alternatively, points in image space can be projected into 3D rays in world space (from the near to the far clipping planes for example), multiplying by the inverse projection and view matrices for raytracing.