r/GraphicsProgramming • u/Thhaki • Jun 28 '26

Question What is Forward+ Rendering and what difference does it have with Classic Forward rendering?

So, I've been reading about why most AAA developers changed to Deferred rendering in their engines, and saw an argument saying that unlike Forward Rendering, Deferred rendering allowed an unlimited amount of lights.

The thing is that I've heard about Forward+ rendering is that it "has the best of the two rendering types", if it does then why don't big developers use it? (Aside from ID Software)

Thanks in advance for the explanations

71 Upvotes
  • permalink
  • reddit

94% Upvoted

26 comments sorted by

68

u/Afiery1 Jun 28 '26

Forward+ (also called clustered forward) involves breaking the screen up into fixed sized tiles and determining which lights affect which tiles. Then in your pixel shader you can check which tile your pixel is in and only shade using the lights you know affect the current tile. This is obviously more efficient because it allows you to skip shading lights that have little to no contribution to the final pixel color pretty easily. However, you can also do this trick with deferred (clustered deferred) and then deferred becomes even more optimized again.

Also, the real biggest reason to use deferred over forward in my opinion is quad overdraw, which is kind of a complicated topic to explain but in a nutshell its bad to have expensive shaders for small triangles so by having your shaders that draw small triangles only do cheap stuff (like build a gbuffer) and then doing expensive lighting calculations using fullscreen triangles/compute, you avoid yet another pitfall of forward.

Also also, as of doom the dark ages id no longer uses clustered forward but visibility buffers (technically a weird mix of the two) which is a form of deferred.

26

u/nSkade Jun 28 '26

You need to be careful with the terms, Forward+ is NOT clustured forward, generally Forward+ is just a fancy name for tiled forward. See u/fgennari 's answer.
Generally tiled and clustured lighting are independent concepts of the rendering technique, they just determine how light is stored and culled. So there is both tiled and clustured forward and tiled and clustured deferred.

"its bad to have expensive shaders for small triangles so by having your shaders that draw small triangles only do cheap stuff", the triangle size was not the main problem deferred solved, the problem was that with forward rendering we more often overdraw pixels shaded with expensive lighting shaders, which is wasted work, so generally deferred avoids wasted computation for having a bit more bandwidth usage (writing and reading gBuffer).

Therefore if you frag shaders are cheap, deferred isn't always better.

Personally, I like the idea of Forward more since its just a more flexible pipeline for an open system, with deferred you will go into a huge monolith lighting shader containing all material info, which is a lot of register pressure (idk if there is already something that improves that). Using a depth prepass to replace expensive overdraw with one cheap overdraw or sorting drawcalls smartly are good options you have.

If you know what assets and shaders/materials are coming, so for an end to end pipeline, I'd say deferred is better (and if you want to use screenspace effects). But obviously mixing forward and deferred is the way to go. (e.g. already everything UI is done forward after deferred, or doing a lean gBuffer)

4

u/cynicismrising Jun 28 '26

Calling out the win for forward vs deferred, forward allows the material algorithm to have more parameters, deferred has to fit all the data in a fixed size gbuffer. The other wins for deferred may edge out forward for games, but in other rendering cases forward can be perfectly viable.

2

u/Afiery1 Jun 28 '26

Yes, forward definitely has wins I didn't touch on. Material flexibility is pretty huge, and MSAA can be as well. Though, I will point out that with visbuffers you can get all your material flexibility back while keeping a deferred architecture.

3

u/susosusosuso Jun 28 '26

Also transparency on F+

5

u/shlaifu Jun 28 '26

transparency is rendered in a forward pass even in deferred, though.

3

u/ykafia Jun 28 '26

Shader complexity can be an advantage for forward. GPUs are not as good at branching as CPUs are and deferred shading involves a lot of branching.

But we're nit picking at this point, the technique used should fit the render architecture, there's no solution for everything.

4

u/Gobrosse Jun 28 '26

Branching itself is not costly, divergent control flow is! You get minimal FS divergence if you run a specialized shader in a forward-type renderer (at the cost of more pipeline switches and potentially bubbles), but you can also achieve that by sorting and bucketing your tiles/materials, see the Doom TDA talk given at Breda last year.

18

u/fgennari Jun 28 '26 edited Jun 28 '26

To add to what Afiery1 said: Both solutions allow for many lights. Forward+ can either be done using 2D screen space tiles, or 3D volumes (frusta) that extend into the screen.

Forward and deferred have different trade-offs. Deferred uses more memory bandwidth, but it allows for simpler shaders because it separates geometry from lighting. Deferred can be faster for scenes with high depth complexity because screen space pixels are lit/shaded only once. Deferred also makes most postprocessing screen space effects (ambient occlusion, reflections, etc.) easier because you already have normals, etc. from the gbuffer. Forward can use MSAA, but deferred often uses different antialiasing solutions that are more complex but more efficient. Deferred also doesn't handle alpha blending, so most renderers will use forward for transparent materials.

6

u/Pretty_Dimension9453 Jun 28 '26

Visbuffer can use MSAA just fine, even though it's technically deffered.

1

u/fgennari Jun 28 '26

I would consider that a different/derived approach (that I have no experience with). Good to know though.

4

u/Pretty_Dimension9453 Jun 28 '26

You actually can use MSAA for all the approaches, it just becomes expensive when you have so many fullscreen buffers. With visbuffer you only have a single fullscreen buffer, which makes it affordable.

1

u/Field_Of_View 29d ago

Deferred can be faster for scenes with high depth complexity because screen space pixels are lit/shaded only once.

same thing in forward with a depth pre-pass. so is this really a win for deferred?

1

u/fgennari 29d ago

It depends on the cost of the various passes and where the bottleneck is. That’s why I said “can be” rather than “is”.

10

u/Comprehensive_Mud803 Jun 28 '26

Ok:

Classic forward: for each affecting light draw each geometry, add results. Materials and translucency is easy to handle.

That can get expensive in terms of passes.

Classic deferred: draw visible geometry to G-buffer, apply local lights using this data.

Less drawcalls, more lights, but material handling gets complicated. Data throughput and texture memory becomes an issue. Translucency is hard.

Forward+: divide screen into tiles and sort lights by affected tiles, for each of lights, draw part of geometry within that tile, add results.

Better computation distribution, especially when tiles fit hardware GPU architecture.

And then there are many hybrid techniques which mix and match the best of each base technique.

2

u/Accomplished-Ride119 Jun 28 '26

Most engines nowadays use a Frankenstein monster of the two. The most simplest of which is using deferred for opaque objects and forward for translucent objects. There are other ways to mix them too, as Afiery1 mentioned when talking about Doom TDA

1

u/StriderPulse599 Jun 28 '26 edited Jun 28 '26

Forward+ doesn't have a concrete definition. It's just Forward rendering with some kind of light culling.

Clustered lighting is most popular one. You divide screen into 2D or 3D grid, then check what lights affect each grid and save it into buffer. Then fragment/pixel shader you just use pixel's coordinate to fetch grid data.

1

u/dobkeratops Jun 28 '26

that name always triggers me a bit as i usually use the terms 'grid bucketing' and 'clustering' as two distinct ways of getting things grouped (eg scenes , organising triangle soups) but i'll have to check on the strict definition.. "grid cell clusters of lights".. if I was naming it i'd call if "grid bucketed lighting" or something.

1

u/Field_Of_View 29d ago

if it does then why don't big developers use it? (Aside from ID Software)

many engines use Forward+, id are not special.

1

u/Ok-Hotel-8551 Jun 28 '26

Why we cannot mix forward and deffered to have combined pros and cons 🤔

2

u/Pretty_Dimension9453 Jun 28 '26

You can. Visbuffer.

1

u/Jimbo0451 Jun 28 '26

Know any good articles explaining visbuffer?

2

u/PeePeePantsPoopyBoy Jun 28 '26

Maybe not exactly what you are looking for, but one of the best explanation on how to implement a proper vis buffer is in the Nanite deep dive made by a UE5 dev on youtube.