Search Results
7/24/2025, 11:21:22 AM
>>716246417
>>716246639
>>716268540
More specifically, deferred rendering allows for more lights in a scene than forward rendering because they DEFER the lighting until later in the pipeline. Forward has performance issues when you go past a few dynamic lights in a scene since it's all done in sequential order.
However, this has all been resolved over a decade ago, and modern devs are too incompetent and/or stuck in their ways to go back to forward. There is now Clustered Shading, which can be used for either rendering method, that makes it possible to have literal thousands of lights in a scene while maintaining performance.
https://www.aortiz.me/2018/12/21/CG.html
Most of these people use a deferred base, however. Even the example above.
Some other notes:
>Deferred has increased and inherent latency that can't be mitigated to an extent to match forward's response times. If you ever thought that games used to be more responsive, you're completely right.
>Deferred rendered games already have to actually do forward rendering passes on anything involving transparency, like glass and subsurface materials.
>A Visibility Buffer renderer is supposed to be the next step. Basically UE5's Nanite, but on a very low level and universal fashion that it's actually performant. Also works with anything on-screen regardless of material; currently, not everything in UE5 can use Nanite, like foliage, unless you do some very specific tricks that Nanite is not currently made or optimized for.
>Rendering methods are not holistic in implementation. This is partially the reason Doom: The Dark Ages runs like hot ass, despite using SOME aspects of a visibility buffer renderer in their engine; it has hacked together to an existing, deferred/forward renderer. The forced ray tracing doesn't help. I should also remind everyone that the extremely performant Doom 2016 was done in an almost entirely forward renderer, by the way.
>>716246639
>>716268540
More specifically, deferred rendering allows for more lights in a scene than forward rendering because they DEFER the lighting until later in the pipeline. Forward has performance issues when you go past a few dynamic lights in a scene since it's all done in sequential order.
However, this has all been resolved over a decade ago, and modern devs are too incompetent and/or stuck in their ways to go back to forward. There is now Clustered Shading, which can be used for either rendering method, that makes it possible to have literal thousands of lights in a scene while maintaining performance.
https://www.aortiz.me/2018/12/21/CG.html
Most of these people use a deferred base, however. Even the example above.
Some other notes:
>Deferred has increased and inherent latency that can't be mitigated to an extent to match forward's response times. If you ever thought that games used to be more responsive, you're completely right.
>Deferred rendered games already have to actually do forward rendering passes on anything involving transparency, like glass and subsurface materials.
>A Visibility Buffer renderer is supposed to be the next step. Basically UE5's Nanite, but on a very low level and universal fashion that it's actually performant. Also works with anything on-screen regardless of material; currently, not everything in UE5 can use Nanite, like foliage, unless you do some very specific tricks that Nanite is not currently made or optimized for.
>Rendering methods are not holistic in implementation. This is partially the reason Doom: The Dark Ages runs like hot ass, despite using SOME aspects of a visibility buffer renderer in their engine; it has hacked together to an existing, deferred/forward renderer. The forced ray tracing doesn't help. I should also remind everyone that the extremely performant Doom 2016 was done in an almost entirely forward renderer, by the way.
Page 1