Deferred renderer: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
 
(25 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{LanguageBar|title=Deferred lighting and Deferred shading}}
{{LanguageBar|title=Deferred renderer (shading & lighting)}}
__NOTOC__
__NOTOC__
'''Deferred lighting''' is an alternate lighting technique and modification of '''[[WP:Deferred shading|deferred shading]]''', a screen-space shading technique that allows many lights to be rendered on the scene without significant performance hit.
'''[[WP:Deferred shading|Deferred shading]]''' is a screen-space shading technique that is performed on a second rendering pass, after the vertex and pixel shaders are rendered.


It is much different from the default [[Radiosity]] lighting that comes with {{Src|4}}. It uses many different lighting passes to generate higher quality lighting, with real time shadows.
'''[[WP:Deferred shading#Deferred lighting|Deferred lighting]]''' (also known as Light Pre-Pass) is an modification of Deferred shading, which uses three passes, instead of two in deferred shading, where only the lighting calculations are deferred. The shading is still done in the initial pass, but the lighting component of the shading is calculated later.


{{Src2|4}} games generally use forward rendering like {{hlalyx|4}}, but games like {{d2|4}} use deferred rendering.
Both deferred rendering techniques allows many lights to be rendered on the scene without a significant performance hit, however deferred lighting is slightly more demanding than deferred shading, but deferred lighting uses less memory than deferred shading, and rendering transparency & [[Anti-aliasing#MSAA|MSAA]] support is easier on deferred lighting.
 
Nonetheless, it is much different from the default (usually static) [[radiosity]] lighting that comes with {{Src|4}} (primarily using '''Forward renderer'''). It uses many different lighting passes to generate higher quality lighting, with real-time shadows.
 
{{Src2|4}} games generally use forward rendering, like {{hlalyx|4}}, but games like {{d2|4}} and {{deadlock|4}} use deferred rendering.
==Differences from vanilla radiosity==
==Differences from vanilla radiosity==
When compiling a map in any of {{Valve|4|addtext='s}} games, each map is run through [[VRAD]], which takes data from all the light sources and compile them into a '''lightmap''' texture. While this does provide high-quality and variable lighting, it is completely static, save for the limited ability to toggle on some lights in a scene. The difference between [[radiosity]] and Deferred lighting is that Deferred lighting computes all its lights in real time. The game takes data from the normals of the object, its geometry, its albedo, and its specular lighting to create real time accurate lighting.
When compiling a map in any of {{Valve|4|addtext='s}} games, each map is run through [[VRAD]] (which can take a long time depending on hardware and [[Lighting_optimization|optimizations]]), which takes data from all the light sources and compiles them into a '''lightmap''' texture. While this does provide high-quality and variable lighting, it is completely static, save for the limited ability to toggle on some lights in a scene. The difference between [[radiosity]] and deferred lighting is that deferred lighting computes all its lights in real-time, with a low performance cost ([[cheap]]). The game takes data from the normals of the object, its geometry, its albedo, and its specular lighting to create real-time accurate lighting.
 
==Dynamic lights in forward rendering==
Performance can be significantly reduced if there are too many dynamic light entities like {{code|[[env_projectedtexture]]}} (also used on [[player]]'s flashlight since {{src07}}) in forward rendering. Other dynamic lights such as {{code|light_dynamic}} also reduce performance if the lightmap has a small luxel scale and/or the light has [[Lightstyle|custom appearance]] (lightstyles). Additionally, {{code|env_projectedtexture}} is also limited by the {{src|1}} engine itself (by default), meaning that it only works properly with one {{code|env_projectedtexture}} entity without engine modifications.
 
Deferred lighting (and deferred shading) does not have these issues or limitations and almost an infinite number of dynamic lights can be active with faster performance than with forward rendering. However, there are also other rendering methods such as "Forward+/Tile" or [[Clustered rendering|Clustered Forward]] which can make dynamic lights less demanding on forward renderer (currently {{p2ce|2}} is the only upcoming Source game, along with {{obm|2}} utilizing this technique).


===Features===
==Features==
*Quite cheap realtime lighting and shadows
*Quite cheap real-time lighting and shadows.
*Almost infinite number of dynamic lights that can be active (stock [[Source]] only allows for one {{ent|env_projectedtexture}} at a time)
*Almost an infinite number of dynamic lights that can be active (stock [[Source]] only allows for one {{ent|env_projectedtexture}} at a time).
*High-fidelity [[Godrays]]
*High-fidelity [[godrays]].
*[[Volumetric lighting]]
*[[Volumetric lighting]].
*Light cookies (premade shadow maps)
*Light cookies (premade shadow maps).


===Drawbacks===
==Drawbacks==
*Traditional antialiasing like [[MSAA]] might not work with it like in {{bms|2}} (which was removed and replaced with FXAA because MSAA combined with deferred lighting caused certain models to have glowing outline around it),{{Cite|1}} but it depends how it was implemented into the game. As with {{asd|1}}, and {{lw|1}} is still supported, through it's recommended that you should use post-processing anti-aliasing method instead as they work best with deferred lighting, and has less performance hit.
*Traditional anti-aliasing methods like [[MSAA]] might not work with deferred lighting and deferred shading, like in {{apex|2}} and {{bms|2}} (the latter title replaced it with FXAA because MSAA caused certain models to have a glowing outline),{{Cite|1}} but it depends how it's implemented in the game, as {{asd|1}}, and {{lw|1}} still support it, though it's recommended that you use post-processing anti-aliasing methods instead as they work best with deferred lighting, and have a smaller performance hit. MSAA is also more demanding with deferred lighting, and even more demanding on deferred shading compared to forward rendering, and MSAA is harder to implement on deferred shading, while it was easier to implement on deferred lighting.
*All lightmaps are disabled and only deferred lighting lights the world. {{only|{{asd}}}}
*All lightmaps are disabled and only deferred lighting lights the world. {{only|{{asd}}}}
*Can be more taxing on older systems.
*Can be more taxing on older systems.
Line 25: Line 34:
[[File:Deferred phong ref.png|800px]]
[[File:Deferred phong ref.png|800px]]


==Availability==
==Usage==
Very few {{src|1|nt=1}} games utilize this lighting technique, as it is very complicated to implement, the games that do use this are listed here:
=== Source ===
*{{apex|4}} (using Deferred shading)
Few {{src|1|nt=1}} games utilize this technique, as it's complicated to implement, the games that do use this are:
==== Deferred shading ====
*{{Tfbranch|4}} (including {{apex|4}})
==== Deferred lighting ====
*{{asd|4}}  
*{{asd|4}}  
*{{bms|4}}
*{{lw|4}}
*{{lw|4}}
*{{p2d|4}}
*{{p2d|4}}
*{{bms|4}}
*{{hammer|4}} (Lighting Preview in stock HL2 and {{strata|4}})
*{{hammer|4}} (Lighting Preview in Stock HL2 and {{strata|4}})
**{{Confirm|Hammer use Deferred lighting or shading?}}
=== Source 2 ===
==== Deferred shading ====
* {{Dota2|4}}{{Cite|2}} (formerly {{src|1}} which also use deferred shading)
* {{Deadlock|4}}
* {{Hammer5|nt=0|4}}{{confirm}}


==Tutorials==
==Tutorials==
Line 39: Line 57:
== See also ==
== See also ==
* {{asd|1}}
* {{asd|1}}
* [[Clustered rendering]] - similar technique, can be implemented on both forward and deferred renderer.
* [[Light editor]]
* [[Light editor]]
* [[Volumetric lighting]]
* [[Volumetric lighting]]
* {{w|Deferred lighting}} (Wikipedia)
=== Entities ===
* {{ent|newLight_Point}}
* {{ent|newLight_Point}}
* {{ent|newLight_Spot}}
* {{ent|newLight_Spot}}
* {{ent|light_deferred}}
* {{ent|light_deferred}}
* {{ent|light_deferred_global}}
* {{ent|light_deferred_global}}
* {{w|Deferred lighting}} (Wikipedia)


==External links==
==External links==
Line 54: Line 74:
'''Known Issues - Haloing Around Props/Object'''<br>
'''Known Issues - Haloing Around Props/Object'''<br>
'''MSAA''' is causing outlines around certain objects. MSSA is a performance killer and we hope to have a better solution for anti-aliasing with the Xen release. To remove the haloing/outline, simply turn off MSAA. }}
'''MSAA''' is causing outlines around certain objects. MSSA is a performance killer and we hope to have a better solution for anti-aliasing with the Xen release. To remove the haloing/outline, simply turn off MSAA. }}
{{Ref2|cite id=2|Several commands related to deferred rendering such as {{code|r_deferred_}} can be seen in {{dota2|1}}. Additionally, enabling MSAA via console commands in the original (Source 1) release of Dota 2 will breaks the renderer. Since [https://developer.valvesoftware.com/w/index.php?title{{=}}Dota_2&oldid{{=}}167294 April 27, 2012], it is confirmed that Dota 2 uses deferred shading, and use FXAA (referred as Screen-space Anti-aliasing when the [[Dota 2]] page on VDC was edited in 2012).}}
}}
}}



Latest revision as of 21:18, 31 May 2025

English (en)中文 (zh)Translate (Translate)

Deferred shading is a screen-space shading technique that is performed on a second rendering pass, after the vertex and pixel shaders are rendered.

Deferred lighting (also known as Light Pre-Pass) is an modification of Deferred shading, which uses three passes, instead of two in deferred shading, where only the lighting calculations are deferred. The shading is still done in the initial pass, but the lighting component of the shading is calculated later.

Both deferred rendering techniques allows many lights to be rendered on the scene without a significant performance hit, however deferred lighting is slightly more demanding than deferred shading, but deferred lighting uses less memory than deferred shading, and rendering transparency & MSAA support is easier on deferred lighting.

Nonetheless, it is much different from the default (usually static) radiosity lighting that comes with Source Source (primarily using Forward renderer). It uses many different lighting passes to generate higher quality lighting, with real-time shadows.

Source 2 Source 2 games generally use forward rendering, like Half-Life: Alyx Half-Life: Alyx, but games like Dota 2 Dota 2 and Deadlock Deadlock use deferred rendering.

Differences from vanilla radiosity

When compiling a map in any of Valve Valve's games, each map is run through VRAD (which can take a long time depending on hardware and optimizations), which takes data from all the light sources and compiles them into a lightmap texture. While this does provide high-quality and variable lighting, it is completely static, save for the limited ability to toggle on some lights in a scene. The difference between radiosity and deferred lighting is that deferred lighting computes all its lights in real-time, with a low performance cost (cheap). The game takes data from the normals of the object, its geometry, its albedo, and its specular lighting to create real-time accurate lighting.

Dynamic lights in forward rendering

Performance can be significantly reduced if there are too many dynamic light entities like env_projectedtexture (also used on player's flashlight since Source 2007) in forward rendering. Other dynamic lights such as light_dynamic also reduce performance if the lightmap has a small luxel scale and/or the light has custom appearance (lightstyles). Additionally, env_projectedtexture is also limited by the Source engine itself (by default), meaning that it only works properly with one env_projectedtexture entity without engine modifications.

Deferred lighting (and deferred shading) does not have these issues or limitations and almost an infinite number of dynamic lights can be active with faster performance than with forward rendering. However, there are also other rendering methods such as "Forward+/Tile" or Clustered Forward which can make dynamic lights less demanding on forward renderer (currently Portal 2: Community Edition Portal 2: Community Edition is the only upcoming Source game, along with Operation: Black Mesa Operation: Black Mesa utilizing this technique).

Features

Drawbacks

  • Traditional anti-aliasing methods like MSAA might not work with deferred lighting and deferred shading, like in Apex Legends Apex Legends and Black Mesa Black Mesa (the latter title replaced it with FXAA because MSAA caused certain models to have a glowing outline),[1] but it depends how it's implemented in the game, as Alien Swarm Deferred, and Lambda Wars still support it, though it's recommended that you use post-processing anti-aliasing methods instead as they work best with deferred lighting, and have a smaller performance hit. MSAA is also more demanding with deferred lighting, and even more demanding on deferred shading compared to forward rendering, and MSAA is harder to implement on deferred shading, while it was easier to implement on deferred lighting.
  • All lightmaps are disabled and only deferred lighting lights the world. (only in Alien Swarm Deferred)
  • Can be more taxing on older systems.
  • DX9 SM3 or later only, older DirectX compatibility versions are not supported.

Media

Deferred phong ref.png

Usage

Source

Few Source Engine games utilize this technique, as it's complicated to implement, the games that do use this are:

Deferred shading

Deferred lighting

Source 2

Deferred shading

Tutorials

See also

Entities

External links

References

References
1. Xen Technical Beta and Screenshot by [TC]Ciaиєz ITA:

Known Issues - Haloing Around Props/Object
MSAA is causing outlines around certain objects. MSSA is a performance killer and we hope to have a better solution for anti-aliasing with the Xen release. To remove the haloing/outline, simply turn off MSAA.. Retrieved on May 10, 2024.

2. Several commands related to deferred rendering such as r_deferred_ can be seen in Dota 2. Additionally, enabling MSAA via console commands in the original (Source 1) release of Dota 2 will breaks the renderer. Since April 27, 2012, it is confirmed that Dota 2 uses deferred shading, and use FXAA (referred as Screen-space Anti-aliasing when the Dota 2 page on VDC was edited in 2012)..