Editing Texture mapping (section)

===Hardware implementations===
Texture mapping hardware was originally developed for simulation (e.g. as implemented in the [[Evans and Sutherland]] ESIG and Singer-Link Digital Image Generators DIG), and professional [[Workstation#Graphics workstations|graphics workstations]] such as [[Silicon Graphics]], broadcast [[digital video effect]]s machines such as the [[Ampex ADO]] and later appeared in [[Arcade cabinet]]s, consumer [[video game console]]s, and PC [[video card]]s in the mid-1990s. In [[flight simulation]], texture mapping provided important motion and altitude cues necessary for pilot training not available on untextured surfaces. It was also in flight simulation applications, that texture mapping was implemented for real-time processing with prefiltered texture patterns stored in memory for real-time access by the video processor.<ref>{{cite journal |last1=Yan |first1=Johnson |title=Advances in Computer-Generated Imagery for Flight Simulation |journal=IEEE |date=August 1985 |volume=5 |issue=8 |pages=37–51 |doi=10.1109/MCG.1985.276213 |url=https://ieeexplore.ieee.org/document/4056245|url-access=subscription }}</ref>

Modern [[graphics processing unit]]s (GPUs) provide specialised [[fixed function unit]]s called ''texture samplers'', or [[texture mapping unit|''texture mapping units'']], to perform texture mapping, usually with [[trilinear filtering]] or better multi-tap [[anisotropic filtering]] and hardware for decoding specific formats such as [[S3 Texture Compression|DXTn]]. As of 2016, texture mapping hardware is ubiquitous as most [[System on a chip|SOC]]s contain a suitable GPU.

Some hardware combines texture mapping with [[hidden-surface determination]] in [[Tiled rendering|tile based deferred rendering]] or [[scanline rendering]]; such systems only fetch the visible [[Texel (graphics)|texels]] at the expense of using greater workspace for transformed vertices. Most systems have settled on the [[Z-buffering]] approach, which can still reduce the texture mapping workload with front-to-back [[Sorting algorithm|sorting]].

Among earlier graphics hardware, there were two competing paradigms of how to deliver a texture to the screen:
* '''Forward texture mapping''' iterates through each texel on the texture, and decides where to place it on the screen.
* '''Inverse texture mapping''' instead iterates through pixels on the screen, and decides what texel to use for each.

Inverse texture mapping is the method which has become standard in modern hardware.

====Inverse texture mapping====
With this method, a pixel on the screen is mapped to a point on the texture. Each vertex of a [[rendering primitive]] is projected to a point on the screen, and each of these points is [[UV mapping|mapped to a u,v texel coordinate]] on the texture. A rasterizer will interpolate between these points to fill in each pixel covered by the primitive.

The primary advantage is that each pixel covered by a primitive will be traversed exactly once. Once a primitive's vertices are transformed, the amount of remaining work scales directly with how many pixels it covers on the screen.

The main disadvantage versus forward texture mapping is that the [[memory access pattern]] in the [[texture space]] will not be linear if the texture is at an angle to the screen. This disadvantage is often addressed by [[texture cache|texture caching]] techniques, such as the [[swizzled texture]] memory arrangement.

The linear interpolation can be used directly for simple and efficient [[#Affine texture mapping|affine]] texture mapping, but can also be adapted for [[#Perspective correctness|perspective correctness]].

====Forward texture mapping====
Forward texture mapping maps each texel of the texture to a pixel on the screen. After transforming a rectangular primitive to a place on the screen, a forward texture mapping renderer iterates through each texel on the texture, splatting each one onto a pixel of the [[frame buffer]].

This was used by some hardware, such as the [[3DO Interactive Multiplayer|3DO]], the [[Sega Saturn]] and the [[NV1]].

The primary advantage is that the texture will be accessed in a simple linear order, allowing very efficient caching of the texture data. However, this benefit is also its disadvantage: as a primitive gets smaller on screen, it still has to iterate over every texel in the texture, causing many pixels to be overdrawn redundantly.

This method is also well suited for rendering quad primitives rather than reducing them to triangles, which provided an advantage when perspective correct texturing was not available in hardware. This is because the affine distortion of a quad looks less incorrect than the same quad split into two triangles (see [[#Affine texture mapping|affine texture mapping]] above). The NV1 hardware also allowed a quadratic interpolation mode to provide an even better approximation of perspective correctness.

The existing hardware implementations did not provide effective [[UV coordinates|UV coordinate mapping]], which became an important technique for 3D modelling and assisted in [[Clipping (computer graphics)|clipping]] the texture correctly when the primitive goes over the edge of the screen. These shortcomings could have been addressed with further development, but GPU design has since mostly moved toward inverse mapping.

{{clear}}