Toggle menu
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Forward rendering, also called forward shading, is a real-time rendering technique in which lighting is computed while the scene geometry is rasterized, usually in the fragment (pixel) shader that draws each surface, so that every object is shaded as it is drawn. It is the traditional alternative to deferred shading, which first writes surface attributes such as position, normal and material properties into a set of screen-sized geometry buffers (G-buffers) and computes lighting in a later pass.[1] Modern variants called tiled forward shading, Forward+ and clustered forward shading add a light-culling step that builds per-tile or per-cluster light lists, which lets a forward renderer handle many dynamic lights.[2][3]

Forward rendering is the path that engine makers and platform holders generally recommend for virtual reality (VR). Its main advantage there is that hardware multisample anti-aliasing (MSAA) works with it, while deferred shading does not support MSAA directly. Epic Games added a forward shading renderer to Unreal Engine 4.14 in November 2016 for VR projects, and Meta calls the forward renderer "the recommended rendering path for Meta Quest development".[4][5]

Reviewed 18 October 2026. Checked every claim against the cited papers (Olsson-Assarsson 2011, Harada et al. 2012, Olsson et al. 2012, Deering 1988 and Saito-Takahashi 1990 abstracts, Crossref/DataCite metadata), Vlachos GDC 2015 slides, and Epic, Meta, Unity, Godot, Impulse Gear, AWN and UploadVR pages as of 18 October 2026. About review dates.

How it works

In a traditional forward renderer the GPU processes each object (or batch of geometry) in turn. The vertex stage transforms it, the rasterizer produces fragments, and the fragment shader evaluates the material and every light that affects the object before writing a final color to the framebuffer. Olsson and Assarsson define forward shading as lighting "computed in the fragment (or sometimes, vertex) shader as part of the rasterization of the scene geometry", and in 2011 they described it as probably still the most common approach in real-time applications such as games.[1]

Because lighting is done per object, the renderer has to decide which lights to send with each draw call. Harada, McKee and Yang note that forward rendering "normally requires setting a small fixed number of lights" to limit the number of shader permutations, and that it needs CPU-side management of lights and objects.[2] Unity Technologies' Built-in Render Pipeline shows a common multi-pass arrangement: a base pass renders one per-pixel light together with per-vertex and spherical harmonics lights, lightmaps, ambient and emissive light, and then Unity renders one additional pass for each further per-pixel light affecting the object.[6] Single-pass forward renderers instead evaluate all relevant lights in one shading pass; the Oculus Unreal Renderer, for example, rendered all geometry and lights in a single pass with an optional depth prepass.[7]

The main weakness of forward shading is wasted work on hidden surfaces. When several surfaces cover the same pixel (overdraw), each one is fully shaded, including surfaces that are later hidden. The usual remedy is a depth prepass (pre-z pass): the scene is first drawn into the depth buffer only, so that the shading pass can reject hidden fragments early. Olsson and Assarsson describe this as a trade-off between the cost of the extra geometry pass and the redundant shading it avoids.[1]

Comparison with deferred shading

Deferred shading splits rendering into a geometry pass, which stores per-pixel surface attributes in G-buffers, and a lighting pass that reads those buffers and applies the lights.[1] Olsson, Billeter and Assarsson trace the idea to a 1988 hardware design by Michael Deering and colleagues, followed by a more general method using full-screen G-buffers in 1990.[3] Deering's paper described a pipeline of triangle processors that rasterized geometry, followed by a separate pipeline of shading processors that applied Phong shading with multiple light sources.[8] The G-buffer (geometric buffer) comes from Takafumi Saito and Tokiichiro Takahashi, who in 1990 stored one geometric property per buffer, such as the depth or normal vector of each pixel, so that image-space enhancement could run as a post-process.[9]

Harada and co-authors summarize the strengths of deferred techniques as the ability to use many lights, the decoupling of lighting from geometric complexity, and manageable shader combinations. They list limited material variety, higher memory and bandwidth requirements, difficulty with transparent objects, and the lack of hardware anti-aliasing support as its disadvantages.[2] Transparent surfaces are a particular problem because the G-buffer holds only one layer per pixel, so deferred renderers usually draw transparent geometry with a separate forward pass.[1] A related method, deferred lighting (also called light pre-pass rendering), computes only lighting in the deferred pass and adds a second geometry pass for final shading.[1]

The following table summarizes the trade-offs as described in the sources above.

Property Forward shading Deferred shading
Where lighting is evaluated In the fragment shader while each surface is rasterized In a separate pass that reads the G-buffers
Hardware MSAA Works directly Not supported directly
Transparency Drawn in the same pipeline Needs a separate forward pass
Material and lighting models Any shader per material Limited to what the G-buffer stores
Cost driver Shading of overdrawn fragments; number of lights per object G-buffer memory and bandwidth

Tiled, Forward+ and clustered variants

Tiled shading groups lights into screen-space tiles, each holding a list of lights that may affect it, so that each pixel loops only over the lights in its tile. Before 2011 it had been discussed in the game development community as tiled deferred shading, mainly as a way to avoid the bandwidth cost of reading the G-buffers again for every light that affects a fragment. In a 2011 article in the Journal of Graphics, GPU, and Game Tools, Ola Olsson and Ulf Assarsson of Chalmers University of Technology gave a detailed description of the technique and introduced tiled forward shading, which applies the same light grid to a forward renderer. They wrote that tiled forward shading keeps many advantages of deferred shading, such as decoupling light management from geometry, while full-screen anti-aliasing and transparency are "trivially supported". In their tests tiled deferred shading had the least variable worst-case performance, scaled best with faster GPUs and was especially suitable for many lights, while tiled forward shading was competitive for scenes with fewer lights.[1]

Forward+ was presented by Takahiro Harada, Jay McKee and Jason C. Yang of AMD (Advanced Micro Devices) in a short paper at Eurographics 2012. The method extends a forward pipeline with three stages: a depth prepass, a GPU compute-shader light-culling stage that builds a list of light indices for each screen tile, and a final shading pass that reads the list for the pixel's tile. The authors state that Forward+ increases the workload of the final shader but "theoretically requires less memory traffic" than compute-based deferred lighting, and that it removes the restriction on materials and lighting models that deferred techniques impose. They call the depth prepass essential, because overdraw is especially expensive when each fragment evaluates a list of lights.[2]

Clustered shading was introduced by Olsson, Markus Billeter and Assarsson at High-Performance Graphics 2012. Tiled methods bound each tile by the minimum and maximum depth of its pixels, so a tile containing a depth discontinuity covers a large empty volume and receives too many lights. Clustered shading instead groups view samples into 3D clusters (optionally also by surface normal), using exponentially spaced depth slices in view space so that clusters stay roughly cube-shaped. The paper reports fewer lighting computations than tiled shading, better worst-case behavior, and real-time scenes with up to around one million lights. The authors note that their clustered forward variant performed similarly to tiled deferred shading in one animated test scene while inherently supporting MSAA and custom material shaders; it requires a depth prepass, which is used to build the clusters.[3]

Applications in VR and AR

Why VR renderers favor forward paths

Anti-aliasing is the most cited reason. In his GDC 2015 talk "Advanced VR Rendering", Valve's Alex Vlachos treated 4x MSAA as the minimum quality level for VR and stated that "Forward renderers win for antialiasing because MSAA just works"; Valve used 8x MSAA when performance allowed.[10] Temporal anti-aliasing (TAA), the usual alternative in deferred renderers, behaves poorly in a headset. Epic's documentation says that the constant sub-pixel movement introduced by head tracking makes TAA blurry in VR, which makes MSAA the better choice there; it also reports that in Epic's tests MSAA increased GPU frame time by about 25% compared with TAA, depending on content.[11]

Performance and bandwidth are the other reasons. In May 2016 Oculus engineer Pete Demoreuille described the Oculus Unreal Renderer, a single-pass forward renderer with clustered lighting based on the 2012 Olsson paper, written for the experimental Oculus project Farlands on Unreal Engine 4.11. He wrote that the typical shaders of Rift content were simple and texture-heavy, so Unreal's G-buffer passes were heavily texture-bound; that forward rendering removed G-buffer writes at the cost of extra arithmetic in the shaders; that TAA caused judder and geometric aliasing during head motion; and that forward rendering avoids expensive full-screen passes that can interfere with asynchronous timewarp. Screen-space effects such as SSAO and SSR were dropped because they can introduce stereo disparity. Oculus reported that retrofitting the renderer into Showdown and Dreamdeck freed enough GPU headroom to raise resolution by 15-30%, and it described the renderer as an unmaintained sample rather than a supported SDK.[7]

On standalone headsets, the GPU architecture adds a further argument. Meta's Unity documentation explains that Meta Quest devices use tile-based GPUs that render each screen tile in fast on-chip memory. MSAA samples never need to leave that tile memory, so with Vulkan lazy allocation the multisampled buffers need not exist in main memory. Meta estimates the saving at about 90 MB per eye buffer for 4x MSAA at 1680x1760 (the Meta Quest 3 default resolution) and about 66 MB per eye buffer at 1440x1584 (the Meta Quest 2 default).[12] Unity's own comparison of its rendering paths rates the mobile performance impact of Forward and Forward+ as low and that of Deferred as high, because of the extra passes that build the G-buffer.[13]

Forward paths have limits in VR as well. When Impulse Gear built Farpoint for PlayStation VR on a modified Unreal Engine 4, the team switched from Epic's deferred renderer, which did not support MSAA, to the Oculus clustered forward renderer and saved about 2 ms per frame. In their tests MSAA itself was "not only very slow" but also not very effective at removing the game's aliasing, so they shipped with FXAA instead; supersampling looked better but was described as extremely expensive, and the team added dynamic resolution scaling to balance image quality and frame rate.[14]

Unreal Engine

Unreal Engine 4.14, released in November 2016, introduced "a new forward shading renderer optimized for VR, enabling crisp multi-sampled anti-aliasing (MSAA)". Epic built it for its own VR projects, including Robo Recall, and reported that with that game's settings the forward renderer was about 22% faster than the deferred renderer on an NVIDIA GeForce GTX 970.[4] In the current documentation it is enabled with the Forward Shading option under Project Settings, Rendering; lights and reflection captures are culled to a frustum-space grid, and each pixel iterates over the lights and captures that affect it.[11]

Epic's documentation lists supported features including full support for stationary lights, dynamic shadows from movable objects, any number of unshadowed movable lights, up to four overlapping shadow-casting movable lights, DBuffer decals, capsule shadows, alpha-to-coverage for masked materials and Instanced Stereo. Unsupported features include screen-space techniques (SSR, SSAO and contact shadows), dynamically shadowed translucency, translucency receiving environment shadows from stationary lights, and MSAA on DBuffer decals and motion blur.[11] Epic's XR best-practices page in the Unreal Engine 5.8 documentation tells developers to enable Forward Shading and set the anti-aliasing method to MSAA, alongside Instanced Stereo.[15]

For Meta Quest, Meta notes that Quest devices use Unreal's mobile forward renderer by default and that its Project Setup Tool recommends 4x MSAA for all Quest devices. Meta also notes that Nanite and Lumen require the deferred renderer and are not available with forward shading enabled.[5]

Unity

Unity's Universal Render Pipeline (URP) offers Forward, Forward+, Deferred and Deferred+ rendering paths; Unity suggests Forward for scenes with few lights or for mobile and low-end platforms, and Forward+ for scenes with many lights when Deferred is too slow on the target platform.[13] Forward+ was added in URP 14 (Unity 2022.2) to avoid the per-object light limit of the Forward path.[16] In Forward+, Unity divides the screen into tiles and identifies which lights affect each tile, so there is no limit on lights per object, although a per-camera limit remains.[17] Unity's comparison table for Unity 6.2 gives the following figures:[13]

URP path Realtime lights per object Realtime lights per camera MSAA Mobile performance impact
Forward 9 Up to 257, depending on platform Supported Low
Forward+ Unlimited Up to 256, depending on platform Supported Low
Deferred Unlimited for opaque objects, 9 for transparent Up to 257, depending on platform Not supported High

Meta's best-practices guide for Quest and PC VR in Unity tells developers to "Always use the Forward Rendering path or Forward+" and gives 4x as the generally recommended MSAA level.[18] In Unity's older Built-in Render Pipeline, single-pass instanced stereo rendering is not supported with deferred rendering.[19]

In June 2016 Valve released The Lab Renderer, a free rendering plug-in for Unity that, according to Valve, provides the features it used to ship The Lab. UploadVR reported that it replaced Unity's multi-pass forward renderer, which redrew geometry for each runtime spot or point light, with a single forward pass supporting up to 18 dynamic shadowing lights with MSAA, and that it required all materials to use The Lab's shaders.[20]

Godot

The Godot 4.7 documentation describes three renderers for Godot: Forward+, Mobile and Compatibility. The Forward+ renderer uses clustered forward lighting, while the Mobile and Compatibility renderers use single-pass forward lighting. For XR the documentation recommends the Mobile renderer for both desktop and standalone headsets and describes Forward+ as "Supported, but poorly optimized" for XR. MSAA for 3D is available in all three renderers.[21]

See also

References

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 Ola Olsson, Ulf Assarsson (2011). "Tiled Shading". Journal of Graphics, GPU, and Game Tools, vol. 15, no. 4, pp. 235-251. doi:10.1080/2151237X.2011.621761. https://www.cse.chalmers.se/~uffe/tiled_shading_preprint.pdf. Retrieved 2026-10-18.
  2. ↑ 2.0 2.1 2.2 2.3 Takahiro Harada, Jay McKee, Jason C. Yang (2012). "Forward+: Bringing Deferred Lighting to the Next Level". Eurographics 2012 - Short Papers, pp. 5-8. The Eurographics Association. doi:10.2312/conf/EG2012/short/005-008. https://doi.org/10.2312/conf/EG2012/short/005-008. Retrieved 2026-10-18.
  3. ↑ 3.0 3.1 3.2 Ola Olsson, Markus Billeter, Ulf Assarsson (2012). "Clustered Deferred and Forward Shading". HPG '12: Proceedings of the Conference on High Performance Graphics 2012, pp. 87-96. The Eurographics Association. doi:10.2312/EGGH/HPG12/087-096. https://www.cse.chalmers.se/~uffe/clustered_shading_preprint.pdf. Retrieved 2026-10-18.
  4. ↑ 4.0 4.1 "Unreal Engine 4.14 Now Available". Animation World Network. 2016-11-17. https://www.awn.com/news/unreal-engine-414-now-available. Retrieved 2026-10-18.
  5. ↑ 5.0 5.1 "Forward Shading Renderer". Meta Horizon OS Developers. Meta Platforms. 2026-04-14. https://developers.meta.com/horizon/documentation/unreal/unreal-forward-renderer/. Retrieved 2026-10-18.
  6. ↑ "Forward rendering path in the Built-In Render Pipeline". Unity Manual (Unity 6.2). Unity Technologies. https://docs.unity3d.com/6000.2/Documentation/Manual/RenderTech-ForwardRendering.html. Retrieved 2026-10-18.
  7. ↑ 7.0 7.1 Pete Demoreuille (2016-05-25). "Optimizing the Unreal Engine 4 Renderer for VR". Meta Horizon OS Developers Blog. Oculus. https://developers.meta.com/horizon/blog/introducing-the-oculus-unreal-renderer/. Retrieved 2026-10-18.
  8. ↑ Michael Deering, Stephanie Winner, Bic Schediwy, Chris Duffy, Neil Hunt (1988-06). "The triangle processor and normal vector shader: a VLSI system for high performance graphics". ACM SIGGRAPH Computer Graphics, vol. 22, no. 4 (SIGGRAPH '88), pp. 21-30. ACM. doi:10.1145/378456.378468. https://doi.org/10.1145/378456.378468. Retrieved 2026-10-18.
  9. ↑ Takafumi Saito, Tokiichiro Takahashi (1990-09). "Comprehensible rendering of 3-D shapes". ACM SIGGRAPH Computer Graphics, vol. 24, no. 4 (SIGGRAPH '90), pp. 197-206. ACM. doi:10.1145/97880.97901. https://doi.org/10.1145/97880.97901. Retrieved 2026-10-18.
  10. ↑ Alex Vlachos (2015). "Advanced VR Rendering". Game Developers Conference 2015. Valve. https://media.steampowered.com/apps/valve/2015/Alex_Vlachos_Advanced_VR_Rendering_GDC2015.pdf. Retrieved 2026-10-18.
  11. ↑ 11.0 11.1 11.2 "Forward Shading Renderer in Unreal Engine". Epic Developer Community. Epic Games. https://dev.epicgames.com/documentation/en-us/unreal-engine/forward-shading-renderer-in-unreal-engine. Retrieved 2026-10-18.
  12. ↑ "OpenXR Meta Quest Support settings". Meta Horizon OS Developers. Meta Platforms. 2026-10-07. https://developers.meta.com/horizon/documentation/unity/unity-openxr-settings-quest/. Retrieved 2026-10-18.
  13. ↑ 13.0 13.1 13.2 "Choose a rendering path in URP". Unity Manual (Unity 6.2). Unity Technologies. https://docs.unity3d.com/6000.2/Documentation/Manual/urp/rendering-paths-comparison.html. Retrieved 2026-10-18.
  14. ↑ Victor Ceitelis, Greg Koreman (2018-03-15). "A Look Inside Farpoint's Rendering Techniques for VR". Impulse Gear Developer Blog. Impulse Gear. https://www.impulsegear.com/a-look-inside-farpoints-rendering-techniques-for-vr. Retrieved 2026-10-18.
  15. ↑ "XR Best Practices in Unreal Engine". Epic Developer Community. Epic Games. https://dev.epicgames.com/documentation/en-us/unreal-engine/xr-best-practices-in-unreal-engine. Retrieved 2026-10-18.
  16. ↑ "What's new in URP 14 (Unity 2022.2)". Universal RP 14.0 Documentation. Unity Technologies. https://docs.unity3d.com/Packages/[email protected]/manual/whats-new/urp-whats-new.html. Retrieved 2026-10-18.
  17. ↑ "Forward and Forward+ rendering paths in URP". Unity Manual (Unity 6.2). Unity Technologies. https://docs.unity3d.com/6000.2/Documentation/Manual/urp/rendering/forward-rendering-paths.html. Retrieved 2026-10-18.
  18. ↑ "Best practices for Quest and PCVR". Meta Horizon OS Developers. Meta Platforms. 2024-09-15. https://developers.meta.com/horizon/documentation/unity/unity-best-practices-intro/. Retrieved 2026-10-18.
  19. ↑ "Stereo rendering". Unity Manual (Unity 6.2). Unity Technologies. https://docs.unity3d.com/6000.2/Documentation/Manual/SinglePassStereoRendering.html. Retrieved 2026-10-18.
  20. ↑ Ian Hamilton (2016-06-02). "HTC Vive Users Could Soon See Big Game Performance Improvements". UploadVR. https://uploadvr.com/valve-releases-lab-renderer-tools-increased-vr-performance/. Retrieved 2026-10-18.
  21. ↑ "Overview of renderers". Godot Engine documentation (4.7). Godot Engine. https://docs.godotengine.org/en/stable/tutorials/rendering/renderers.html. Retrieved 2026-10-18.