Editing Texture mapping (section)

===Subdivision for perspective correction===
Every triangle can be further subdivided into groups of about 16 pixels in order to achieve two goals. First, keeping the arithmetic mill busy at all times. Second, producing faster arithmetic results.{{vague|date=March 2020}}

====World space subdivision====
For perspective texture mapping without hardware support, a triangle is broken down into smaller triangles for rendering and affine mapping is used on them. The reason this technique works is that the distortion of affine mapping becomes much less noticeable on smaller polygons. The [[Sony PlayStation]] made extensive use of this because it only supported affine mapping in hardware but had a relatively high triangle throughput compared to its peers.

====Screen space subdivision====
[[File:Texturemapping subdivision.svg|thumb|200 px|Screen space sub division techniques. Top left: Quake-like, top right: bilinear, bottom left: const-z]]

Software renderers generally preferred screen subdivision because it has less overhead. Additionally, they try to do linear interpolation along a line of pixels to simplify the set-up (compared to 2d affine interpolation) and thus again the overhead (also affine texture-mapping does not fit into the low number of registers of the [[x86]] CPU; the [[68000]] or any [[RISC]] is much more suited).

A different approach was taken for ''[[Quake (video game)|Quake]]'', which would calculate perspective correct coordinates only once every 16 pixels of a scanline and linearly interpolate between them, effectively running at the speed of linear interpolation because the perspective correct calculation runs in parallel on the co-processor.<ref>Abrash, Michael. ''Michael Abrash's Graphics Programming Black Book Special Edition.'' The Coriolis Group, Scottsdale Arizona, 1997. {{ISBN|1-57610-174-6}} ([http://www.gamedev.net/reference/articles/article1698.asp PDF] {{Webarchive|url=https://web.archive.org/web/20070311022026/http://www.gamedev.net/reference/articles/article1698.asp |date=2007-03-11 }}) (Chapter 70, pg. 1282)</ref> The polygons are rendered independently, hence it may be possible to switch between spans and columns or diagonal directions depending on the orientation of the [[polygon normal]] to achieve a more constant z but the effort seems not to be worth it.

====Other techniques====
Another technique was approximating the perspective with a faster calculation, such as a polynomial. Still another technique uses 1/z value of the last two drawn pixels to linearly extrapolate the next value. The division is then done starting from those values so that only a small remainder has to be divided<ref>{{cite patent
 | inventor-last = Spackman
 | inventor-first = John Neil
 | issue-date = 1998-04-14
 | title = Apparatus and method for performing perspectively correct interpolation in computer graphics
 | patent-number = 5739818
 | country-code = US
}}</ref> but the amount of bookkeeping makes this method too slow on most systems.

Finally, [[Build engine|the Build engine]] extended the constant distance trick used for Doom by finding the line of constant distance for arbitrary polygons and rendering along it.