drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2025-03-04 21:04:02 +01:00
parent 638265b6fe
commit 07603f7b64
14 changed files with 1975 additions and 1933 deletions
Download patch file Download diff file Expand all files Collapse all files

10
deferred_shading.md
View file

@ -1,12 +1,12 @@
# Deferred Shading
In computer [graphics](graphics.md) programming deferred shading is a technique for speeding up the rendering of (mainly) [shaded](shading.md) 3D graphics (i.e. graphics with textures, materials, [normal maps](normal_mapping.md) etc.). It is nowadays used in many advanced 3D engines. In principle of course the idea may also be used in 2D graphics and outside graphics.
In computer [graphics](graphics.md) [programming](programming.md) deferred shading refers to a specific technique of speeding up the rendering of (mainly) [shaded](shading.md) [3D graphics](3d_rendering.md) (i.e. graphics with textures, materials, [normal maps](normal_mapping.md) etc.) by delaying (deferring) [shading](shading.md) to a time at which it's already known which parts of the rendered scene are visible. Today this technique is in very common use and will be found practically in every advanced 3D engine. In principle the general idea behind it may also be used in 2D graphics (and possibly even outside graphics).
The principle is following: in normal forward shading (non-deferred) the shading computation is applied immediately to any rendered pixel (fragment) as they are rendered. However, as objects can overlap, many of these expensively computed pixels may be overwritten by pixels of other objects, so many pixels end up being expensively computed but invisible (this is called *overdraw*). This is of course wasted computation. Deferred shading only computes shading of the pixels that will end up actually being visible -- this is achieved by **two rendering passes**:
The principle is following: in normal forward (non-deferred) shading the shading computation is applied immediately to any rasterized [pixel](pixel.md) (fragment). However, as objects can overlap, many of these expensively computed pixels may be overwritten by pixels of other objects, so many pixels end up being expensively computed but eventually invisible (this is called *overdraw*). This is of course wasted computation. Deferred shading only computes shading of the pixels that will end up actually being visible -- this is achieved with **two rendering passes**:
1. At first geometry is rendered without shading, only with information that is needed for shading (for example [normals](normal.md), material IDs, texture IDs etc.). The rendered image is stored in so called G-buffer which is basically an image in which every pixel stores the above mentioned shading information.
1. Geometry is first rendered without shading, only with information that is needed for shading (for example [normals](normal.md), material IDs, texture IDs etc.). The rendered image is stored in so called *G-buffer* which is basically an image where every pixel stores the above mentioned shading information.
2. The second pass applies the shading effects by applying the pixel/fragment [shader](shader.md) on each pixel of the G-buffer.
This is especially effective when we're using very expensive/complex pixel/fragment shaders AND we have many overlapping objects. **Sometimes deferred shading may be replaced by simply ordering the rendered models**, i.e. rendering front-to-back, which may achieve practically the same speed up. In simple cases deferred shading may not even be worth it -- in [LRS](lrs.md) programs we may use it only rarely.
This is especially effective when using very expensive/complex pixel/fragment shaders while at the same time having many overlapping objects. **Sometimes deferred shading may be replaced by simply ordering the rendered models**, i.e. rendering front-to-back, which may achieve practically the same speed up (but may in turn lose speed at the sorting step). In simple cases deferred shading may not even be worth it -- in [LRS](lrs.md) programs we may use it only rarely. As always, the [overhead](overhead.md) may make many cases worse off than going the simpler way, plus we add [bloat](bloat.md).
Deferred shading also comes with complications, for example **rasterization [anti aliasing](antialiasing.md) can't be used** because, of course, anti-aliasing in G-buffer doesn't really make sense. This is usually solved by some [screen-space](screen_space.md) antialiasing technique such as [FXAA](fxaa.md), but of course that may be a bit inferior. **Transparency also poses an issue**.
Deferred shading also comes with complications, for example **rasterization [anti aliasing](antialiasing.md) can't be used** because, well, anti-aliasing in G-buffer doesn't really make sense. This is usually solved by some [screen-space](screen_space.md) antialiasing technique such as [FXAA](fxaa.md), but of course that may be a bit inferior. **Transparency also poses an issue** (for blending G-buffer would somehow have to store information about more than one surface).