With classic Forward rendering you render the entire scene once for each light. That’s how 3.0 works.
So basically 100 objects with 100 lights = 10000 draw calls.
With classic deferred rendering you render a geometry pass to create a gbuffer with different informations : material color, position of the pixel in world space or view space (or depth), normals, everything you need to compute lighting. Then you create some kind of light buffer that is essentially a texture with light influence on screen (usually a gizmo geom for each light type). then from those 2 buffers, you compute light in a post process.
So basically 100 objects with 100 lights = 200 draw calls (note that the light pass is usually less expensive than the gbuffer pass).
This allows you to build more complex dynamic lighting into your scene and keep a decent frame rate.
Sounds like a good solution and you may wonder why it’s not in JME.
- Well first it’s a complete different pipeline, and @FrozenShade here can assess this. So basically a lot more of things to maintain.
- Second, it makes transparency a lot more difficult to handle (like is was easy before).
- Third, MSAA becomes unusable (though it’s not true anymore since opengl3.0, but it’s even more a perf killer in deferred, hence the FXAA, techniques that popped up in the industry).
Why we don’t need it (IMHO) :
- JME3.1 introduced 2 tremendous improvements in light management : Light Culling and Single Pass Lighting.
- Light Culling compute for each geometry on each frame what light influence it.
So when you have a scene with 100 geoms and 100 lights there is a good chance that each geom is actually lit by a very small subset of those lights. So even with the multipass lighting this greatly reduce the number of draw calls. - Single Pass Lighting allows you to render a geometry with lighting coming from several lights in one pass (the number of light can be changed but it’s fixed for one scene, this may be improved in 3.2).
So let’s say we render 8 lights per pass, if a geom is influenced by 12 lights at the same time, there will be 2 passes for this geom.
So if your 100 geom and 100 lights scene is well partitioned there is a good chance that it will be rendered in one pass making it a 100 draw calls pass. Maybe more of course depending on the case.
-
Lighting in modern graphic industry is more and more handled by Global illumination through Image Base Lighting.
That’s basically what we have with PBR, a light probe holds lighting information virtually coming from thouthands of lights. This greatly reduce the need of dynamic standard lights. -
the rise of 4k screens makes the deferred lighting technique gbuffer huge… and this is a problem for GPU bandwidth as you need to upload huge amount of data to the GPU on each frame. Though…this may just be question of time as GPU are just kicking new asses everyday.
All this combined is IMO making the need of deferred lighting pretty worthless.
EDIT: @FrozenShade note that I’m not saying what you did is worthless, it’s not like you had any choice back then, and you did a pretty good work.