The strong points that I see for deferred rendering going forward have to do with decoupling geometric and lighting complexities elegantly using the already-screamin'-fast hardware rasterizer at an extremely fine granularity (pixels). Sure you can do this at an object, spatial partition or larger level (scene graph) but these approaches are more complicated, less precise and do not scale as well with fully dynamic scenes. I'm not saying that they can't be made to work well - certainly they can - but they offer few
theoretical advantages over the light contribution "compositing" approach, which tends to be what people are referring to when they talk about "Deferred Lighting".
Quote:Original post by wolf
So what I would like to suggest is to look at whatever your game needs and start with a renderer that defers depth data and shadow data (quite common nowadays) and then think about defering normal data and if you want split up the light equation into light properties and material properties.
Certainly that's a good approach and I think people who do it this way see very clearly that the BRDFs/BSDFs are quite separate in reality and thus deferred lighting is almost a more natural way to specify and evaluate the lighting and surface reflectance models.
That said there's a caveat to some of the deferred shadowing stuff that people are doing nowadays: you lose shadow texture coordinate derivatives unless you write them out separately or compute them analytically. With these, you lose all hope of properly filtered shadows... you can "soften the edges" but they'll still alias like crazy when viewed from certain angles - Crysis being the latest poster child for this.
Quote:Original post by wolf
Let me just add one more argument to the discussion: current and future hardware prefers arithmetic instructions over memory. So the speed of memory does not increase with the same pace as the speed of arithmetic instructions. When you design a renderer you want to balance this. The design that is described in many documents will perform worse in future hardware therefore because the increase in arithmetic instruction speed will be higher than the increase in memory speed and you will want to do things with as less render targets as possible.
While it's true that memory speeds are scaling less rapidly than arithmetic ability, the key point to note is that deferred rendering offers entirely
predictable, streaming memory access. Thus the latency (and bandwidth to some extent) of these transactions can be entirely hidden by a proper cache/local storage hierarchy. These are already in place on modern GPUs and we're moving even more towards user-managed "scratch pads" them with things like the Cell's local store, the G80's parallel data cache and arguably the 360's EDRAM. It's really random access (gather/scatter) that's the problem.
It's also important to note that scene and shader complexities are increasing at a far more rapid rate than framebuffer resolutions, which motivates image-space lighting algorithms like Deferred Lighting. Sure there will probably be a 2-3 fold increase in LCD pixel density in the next 10 years, but I expect that in the same time we'll be wanting tons of fully dynamic lights (from particle systems say) affecting fully dynamic scenes (from physics simulation say). GI approximations also come to mind, many of which use deferred lighting-style algorithms to efficiently accumulate indirect light.
Anyways it's a big huge topic certainly, but the shift from strictly forward rendering to more hybrid engines has actually been rather fast so far... capable GPUs have only been around for a few years. It will be interesting to see how the state of the art advances in the next little while but if the recent papers in real-time graphics are indicative (they almost always are), deferred lighting/shading is here to stay for the long haul.
Now what gets really interesting is looking at tile-based deferred renderers in GPU hardware, but that's a subject for Beyond3D I think :)
