Archive and release the study notes and excerpts of some articles in the past;
Rich lighting environment will increase a lot of Draw Call and Overdraw in forward rendering ; Delayed rendering can be used to solve this problem;
In forward rendering , we need to calculate lighting in the fragment shader, which means that when we use multiple lights, a large amount of Overdraw will be generated. Although there are occlusion culling and early-z to reduce overdraw, the consumption of GPU operations still has an exponential growth trend:
In deferred rendering , relevant information will be rendered to the deferred buffer (also known as G-buffer), such as depth, normal, color, etc.; when all the fragments are rendered, lighting and coloring will be performed; because the size of the deferred buffer is fixed, as the number of lights increases, the consumption of GPU operations will only increase linearly; at the same time, deferred rendering also brings problems.
There are some other problems with deferred rendering:
- Translucent objects are not supported, so after using deferred rendering to draw opaque objects, you need to use forward rendering to draw translucent objects;
- Delayed rendering does not support MSAA (a method of AGAA is described in reference 4);
- For the case of multiple materials, some additional processing is required;
For opaque objects, the rendering results of forward rendering and deferred rendering are equivalent, but for complex lighting environments (point light sources and spotlights), deferred rendering is more efficient;
It should be noted that the parallel light here will use the forward rendering pipeline and render normally in the fragment shader, while only the point light source and spotlight will use deferred rendering; because parallel light will affect all models, it is not very meaningful to use deferred rendering; and for point light source and spotlight, it is necessary to calculate their affected area (shape) to speed up rendering;
Compared with forward rendering, deferred rendering just moves the calculation of (local) lighting back a stage, and the calculation of these lighting is actually equivalent to a post-processing, that is, lighting shader;
Under what circumstances can you consider using deferred rendering?
- In the case of many local light sources, it is best if these light sources do not overlap, especially in night scenes with a lot of dynamic lighting or in small closed spaces, good results can be obtained;
- When there are too many parallel lights, it is not suitable, because these lights will affect all fragments, so it is not more efficient than forward rendering; it is not suitable for outdoor open scenes during the day;
Original link:
Deferred Rendering in StarCraft II Effects and Techniques - Programmer Sought