To install click the Add extension button. That's it.

The source code for the WIKI 2 extension is being checked by specialists of the Mozilla Foundation, Google, and Apple. You could also do it yourself at any point in time.

4,5
Kelly Slayton
Congratulations on this excellent venture… what a great idea!
Alexander Grigorievskiy
I use WIKI 2 every day and almost forgot how the original Wikipedia looks like.
What we do. Every page goes through several hundred of perfecting techniques; in live mode. Quite the same Wikipedia. Just better.
.
Leo
Newton
Brights
Milds

From Wikipedia, the free encyclopedia

Z-buffer data

A depth buffer, also known as a z-buffer, is a type of data buffer used in computer graphics to represent depth information of objects in 3D space from a particular perspective. The depth is stored as a height map of the scene, the values representing a distance to camera, with 0 being the closest. The encoding scheme may be flipped with the highest number being the value closest to camera. Depth buffers are an aid to rendering a scene to ensure that the correct polygons properly occlude other polygons. Z-buffering was first described in 1974 by Wolfgang Straßer in his PhD thesis on fast algorithms for rendering occluded objects.[1] A similar solution to determining overlapping polygons is the painter's algorithm, which is capable of handling non-opaque scene elements, though at the cost of efficiency and incorrect results.

In a 3D-rendering pipeline, when an object is projected on the screen, the depth (z-value) of a generated fragment in the projected screen image is compared to the value already stored in the buffer (depth test), and replaces it if the new value is closer. It works in tandem with the rasterizer, which computes the colored values. The fragment output by the rasterizer is saved if it is not overlapped by another fragment.

When viewing an image containing partially or fully overlapping opaque objects or surfaces, it is not possible to fully see those objects that are farthest away from the viewer and behind other objects (i.e., some surfaces are hidden behind others). If there were no mechanism for managing overlapping surfaces, surfaces would render on top of each other, not caring if they are meant to be behind other objects. The identification and removal of these surfaces are called the hidden-surface problem. To check for overlap, the computer calculates the z-value of a pixel corresponding to the first object and compares it with the z-value at the same pixel location in the z-buffer. If the calculated z-value is smaller than the z-value already in the z-buffer (i.e., the new pixel is closer), then the current z-value in the z-buffer is replaced with the calculated value. This is repeated for all objects and surfaces in the scene (often in parallel). In the end, the z-buffer will allow correct reproduction of the usual depth perception: a close object hides one further away. This is called z-culling.

The z-buffer has the same internal data structure as an image, namely a 2D-array, with the only difference being that it stores a single value for each screen pixel instead of color images that use 3 values to create color. This makes the z-buffer appear black-and-white because it is not storing color information. The buffer has the same dimensions as the screen buffer for consistency.

Primary visibility tests (such as back-face culling) and secondary visibility tests (such as overlap checks and screen clipping) are usually performed on objects' polygons in order to skip specific polygons that are unnecessary to render. Z-buffer, by comparison, is comparatively expensive, so performing primary and secondary visibility tests relieve the z-buffer of some duty.

The granularity of a z-buffer has a great influence on the scene quality: the traditional 16-bit z-buffer can result in artifacts (called "z-fighting" or stitching) when two objects are very close to each other. A more modern 24-bit or 32-bit z-buffer behaves much better, although the problem cannot be eliminated without additional algorithms. An 8-bit z-buffer is almost never used since it has too little precision.

YouTube Encyclopedic

  • 1/5
    Views:
    66 653
    160 849
    30 716
    4 116
    2 885
  • How the Z-Buffer Works - Interactive 3D Graphics
  • Z buffer method | Computer Graphics | lec-52| Bhanu Priya
  • Z-Buffer Algorithm
  • Z-Buffer in Computer Graphics | Computer Graphics by BhanuPriya | Lec-27
  • Z buffer algorithm

Transcription

When an object is rendered into an image, at each pixel, the distance from the object to the camera is used to compute its z depth, a value from 0 to 1. So, here for example, I've rendered a sphere. And at this pixel, I found that the depth of the sphere in 0.6. This value is then checked against the current value stored in the z buffer. Which you'll recall, we've initialized to all ones. If the object's distance is lower than the z depth value stored, the object is closer to the camera. And so the color of the object is then stored in the image's color buffer. So, in this case, the sphere's depth is clearly closer than the maximum value can store in the z depth. So it's visible at this point. Lets say we draw a cube. The cube's depth at this pixel is 0.3, which is closer than the 0.6 that we have storage for what the sphere did. So, since its closer, we use the cube's color at this pixel and replace this value, 0.3 replaces 0.6. Say, the last object we draw is this ground plane. At the pixel, it turns out the ground plane's depth is 0.8. This is higher than the current z depth 0.3. So, the ground plane fails, which is as it should be because the ground plane is obviously farther away than these two objects. The final conclusion of this process is that the current z depth stays at 0.3 and the color that's stored at the pixel, this blue cube, is indeed the color that gets displayed on the screen. By storing a depth at each pixel, the GPU can mindlessly keep track of what object is closest at any given moment. What's interesting to realize is that decades ago, when this idea first came up, of the z buffer, it was considered absurdly expensive because you had to add a big chunk of memory of z depth buffer that was just an outrageous amount. You'd have to add a whole mega byte of memory which would be outrageously expensive. So, this algorithm originally was a terrible idea. And memory costs came down just a tad and now it's the predominant way of rasterizing triangles.

Uses

The Z-buffer is a technology used in almost all contemporary computers, laptops, and mobile phones for performing 3D computer graphics. The primary use now is for video games, which require fast and accurate processing of 3D scenes. The Z-buffer is implemented in hardware within consumer graphics cards. The Z-buffer is also used (implemented as software as opposed to hardware) for producing computer-generated special effects for films.[citation needed]

Furthermore, Z-buffer data obtained from rendering a surface from a light's point-of-view permits the creation of shadows by the shadow mapping technique.[2]

Developments

Even with small enough granularity, quality problems may arise when precision in the z-buffer's distance values are not spread evenly over distance. Nearer values are much more precise (and hence can display closer objects better) than values that are farther away. Generally, this is desirable, but sometimes it will cause artifacts to appear as objects become more distant. A variation on z-buffering which results in more evenly distributed precision is called w-buffering (see below).

At the start of a new scene, the z-buffer must be cleared to a defined value, usually 1.0, because this value is the upper limit (on a scale of 0 to 1) of depth, meaning that no object is present at this point through the viewing frustum.

The invention of the z-buffer concept is most often attributed to Edwin Catmull, although Wolfgang Straßer described this idea in his 1974 Ph.D. thesis months before Catmull's invention.[a]

On more recent PC graphics cards (1999–2005), z-buffer management uses a significant chunk of the available memory bandwidth. Various methods have been employed to reduce the performance cost of z-buffering, such as lossless compression (computer resources to compress/decompress are cheaper than bandwidth) and ultra-fast hardware z-clear that makes obsolete the "one frame positive, one frame negative" trick (skipping inter-frame clear altogether using signed numbers to cleverly check depths).

Some games, notably several games later in the N64's life cycle, decided to either minimize Z buffering (for example, rendering the background first without z buffering and only using Z buffering for the foreground objects) or to omit it entirely, to reduce memory bandwidth requirements and memory requirements respectively. Super Smash Bros. and F-Zero X are two N64 games that minimized Z buffering to increase framerates. Several Factor 5 games also minimized or omitted Z buffering. On the N64 Z Buffering can consume up to 4x as much bandwidth as opposed to not using Z buffering.[3]

Mechwarrior 2 on PC supported resolutions up to 800x600[4] on the original 4 MB 3DFX Voodoo due to not using Z Buffering.


Z-culling

In rendering, z-culling is early pixel elimination based on depth, a method that provides an increase in performance when rendering of hidden surfaces is costly. It is a direct consequence of z-buffering, where the depth of each pixel candidate is compared to the depth of the existing geometry behind which it might be hidden.

When using a z-buffer, a pixel can be culled (discarded) as soon as its depth is known, which makes it possible to skip the entire process of lighting and texturing a pixel that would not be visible anyway. Also, time-consuming pixel shaders will generally not be executed for the culled pixels. This makes z-culling a good optimization candidate in situations where fillrate, lighting, texturing, or pixel shaders are the main bottlenecks.

While z-buffering allows the geometry to be unsorted, sorting polygons by increasing depth (thus using a reverse painter's algorithm) allows each screen pixel to be rendered fewer times. This can increase performance in fillrate-limited scenes with large amounts of overdraw, but if not combined with z-buffering it suffers from severe problems such as:

  • polygons might occlude one another in a cycle (e.g.: triangle A occludes B, B occludes C, C occludes A), and
  • there is no canonical "closest" point on a triangle (e.g.: no matter whether one sorts triangles by their centroid or closest point or furthest point, one can always find two triangles A and B such that A is "closer" but in reality B should be drawn first).

As such, a reverse painter's algorithm cannot be used as an alternative to Z-culling (without strenuous re-engineering), except as an optimization to Z-culling. For example, an optimization might be to keep polygons sorted according to x/y-location and z-depth to provide bounds, in an effort to quickly determine if two polygons might possibly have an occlusion interaction.

Mathematics

The range of depth values in camera space to be rendered is often defined between a and value of .

After a perspective transformation, the new value of , or , is defined by:

After an orthographic projection, the new value of , or , is defined by:

where is the old value of in camera space, and is sometimes called or .

The resulting values of are normalized between the values of -1 and 1, where the plane is at -1 and the plane is at 1. Values outside of this range correspond to points which are not in the viewing frustum, and shouldn't be rendered.

Fixed-point representation

Typically, these values are stored in the z-buffer of the hardware graphics accelerator in fixed point format. First they are normalized to a more common range which is [0, 1] by substituting the appropriate conversion into the previous formula:

Simplifying:

Second, the above formula is multiplied by where d is the depth of the z-buffer (usually 16, 24 or 32 bits) and rounding the result to an integer:[5]

This formula can be inverted and derived in order to calculate the z-buffer resolution (the 'granularity' mentioned earlier). The inverse of the above :

where

The z-buffer resolution in terms of camera space would be the incremental value resulted from the smallest change in the integer stored in the z-buffer, which is +1 or -1. Therefore, this resolution can be calculated from the derivative of as a function of :

Expressing it back in camera space terms, by substituting by the above :

This shows that the values of are grouped much more densely near the plane, and much more sparsely farther away, resulting in better precision closer to the camera. The smaller is, the less precision there is far away—having the plane set too closely is a common cause of undesirable rendering artifacts in more distant objects.[6]

To implement a z-buffer, the values of are linearly interpolated across screen space between the vertices of the current polygon, and these intermediate values are generally stored in the z-buffer in fixed point format.

W-buffer

To implement a w-buffer,[7] the old values of in camera space, or , are stored in the buffer, generally in floating point format. However, these values cannot be linearly interpolated across screen space from the vertices—they usually have to be inverted, interpolated, and then inverted again. The resulting values of , as opposed to , are spaced evenly between and . There are implementations of the w-buffer that avoid the inversions altogether.

Whether a z-buffer or w-buffer results in a better image depends on the application.

Algorithmics

The following pseudocode demonstrates the process of z-buffering:

// First of all, initialize the depth of each pixel.
d(i, j) = infinite // Max length

// Initialize the color value for each pixel to the background color
c(i, j) = background color

// For each polygon, do the following steps :
for (each pixel in polygon's projection)
{
    // Find depth i.e, z of polygon
    //   at (x, y) corresponding to pixel (i, j)   
    if (z < d(i, j))
    {
        d(i, j) = z;
        c(i, j) = color;
    }
}

See also

References

  1. ^ Straßer, Wolfgang (April 26, 1974). "Zukünftige Arbeiten". Schnelle Kurven- und Flächendarstellung auf grafischen Sichtgeräten [Fast curve and surface display on graphic display devices] (PDF) (in German). Berlin. 6-1.{{cite book}}: CS1 maint: location missing publisher (link)
  2. ^ Akenine-Möller, Tomas; Haines, Eric; Hoffman, Naty (2018-08-06). Real-Time Rendering, Fourth Edition. CRC Press. ISBN 978-1-351-81615-1.
  3. ^ How I implemented MegaTextures on real Nintendo 64 hardware, retrieved 2024-01-04
  4. ^ 3D Acceleration Comparison Ep11: Mechwarrior 2 - 3DFX / PowerVR / S3 Virge / ATI Rage / Matrox Mys, retrieved 2024-01-04
  5. ^ The OpenGL Organization. "Open GL / FAQ 2 - Depth Buffer Precision". Retrieved 2017-12-26.
  6. ^ Grégory Massal. "Depth buffer - the gritty details". Archived from the original on 15 October 2008. Retrieved 2008-08-03.
  7. ^ Steve Baker. "Learning to Love your Z-buffer". Retrieved 2018-01-03.

External links

Notes

  1. ^ See Wolfgang K. Giloi [de], J. L. Encarnação, W. Straßer. "The Giloi’s School of Computer Graphics". Computer Graphics 35 4:12–16.
This page was last edited on 6 April 2024, at 17:44
Basis of this page is in Wikipedia. Text is available under the CC BY-SA 3.0 Unported License. Non-text media are available under their specified licenses. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc. WIKI 2 is an independent company and has no affiliation with Wikimedia Foundation.