At the moment, I'm just using a very basic forward rendering schema so it doesn't handle a lot of lights very well.
I've been thinking of swapping to one of the more powerful rendering styles. But I'm having some difficulties trying to figure out which one to use.
They seem to be trying to solve different problems, and possibly getting the same results?
When would you want to use Forward+ or Differed Rendering?
Forward+ allows more material shaders for specific needs. With deferred you are limiting yourself to run one shader on the entire scene. Also Forward+ doesn't have to write a GBuffer so the bandwidth is lowered. I think most people will be moving to Forward+ if possible. MSAA will be cheaper on Forward+. You also don't have to perform any blending operations in Forward+ like you do with deferred.
What do you mean more material shaders? I think several engines have deferred rendering, and has used several different shaders.
Crudely speaking, the cost of rendering in forward is N objects * M lights. This means that heavily lit geometrically complex environments get very expensive. Deferred was developed because the cost of rendering for that approach is N objects + M lights. Lighting in deferred is very cheap, even thousands of them if they're small. I've used deferred pipelines in the past to run dense particle systems with lighting from every particle and stuff like that. The downside is massive bandwidth requirements, alpha blending problems, anti-aliasing problems, and material limitations.
Forward+ and its variations were developed to get the benefits of cheap lighting in deferred, but without all of the other problems deferred has. While bandwidth use is still pretty high, it tends to cooperate much better with more varied materials, alpha blending, and AA. It also leverages compute tasks for better utilization of GPU overall. In general, I would tend to encourage Forward+/tiled forward as the default rendering pipeline of choices on modern desktop/laptop hardware, unless you have a specific reason not to.
There's a lot to go over, but the basics are:
Forward+ (or rather clustered forward+ which is really what you'd use):
Positives:
Easy translucency (still not sorted, but at least it's there).
Easy MSAA.
Easy use of multiple material shading models.
Negatives:
Possibly high overdraw costs or vertex costs, as you might end up doing either a z-prepass and doubling your vertex load, or living with the remaining overdraw costs even after clustered light binning, which can still be more costly if you're running heavy per pixel operations.
Deferred (or rather tiled/clustered deferred, again what you'd really want to use)
Positives:
Extremely predictable costs (shade what's onscreen!)
Low overdraw costs (see above)
Easy use of deferred tricks (soft particles, screenspace raytracing, etc. etc.)
The above is really, really useful. Actually applying shadows can get quite cheap, (deferred shadow masks, or even just drawing them directly into the buffer for point lights), deferred decals, relatively easy area lights, etc. etc.
Negatives:
Translucency is haaard. You need to either do a foward pass (with clustered light binning you can re-use the light bins, so that's useful) or gather all your lighting into a spherical harmonics/guassian grid each frame, then do a screenspace pass on translucency using that (UE4 and Destiny do this).
Material types are more limited; you're limited to your g-buffer size, and need to pay the cost of each material type in each onscreen tile you find it in.
Can't do MSAA easily, though since temporal re-projection AA, morphological AA, and specular AA (toksvig/etc.) have gotten so good, and can be cheaper than MSAA anyway, I don't see the obsession over having MSAA as really justified anymore.
Really, you're going to have to look at each one and figure out what your project needs. Though since you're already doing a straight forward pass, and thus aren't doing any of the savings from all the deferred stuff, it would be simpler and more straightforward to just implement clustered forward plus.
Well it's forward because I needed something that worked while I did other things :P
But the specifics of the game engine is that it's an engine designed for a fantasy setting with an angled downwards facing-rotating camera with baulder's gate style controls.
I don't really plan on static lighting since it can be avoided completely on hardware, and it's possible to have a lot of small lights on the scene. Annnd... fantasy, so particles up the arse.
Well that's not too helpful :mellow:
Lots of particles would suggest foward+ so as to make translucency easier, but there's quite the neat trick with deferred where you can get unlimited tiny lights on screen for a low cost; you basically read emissive materials then spread out as light onto the g-buffer. Obviously doesn't work with offscreen stuff, but any say, emissive particles from fancy fx, can essentially cast a bit of light onto the scene for almost no cost, which can look great with a tons of sparks/sparkly stuff (and helps a lot with emissive particles "sticking out" and not looking like they're part of the scene). That and tons of lights onscreen could mean a lot overdraw for forward+...
Take a look at Emil Perrson's Clustered Shading: http://www.humus.name/Articles/PracticalClusteredShading.pdf
The clustered portion (binning lights in Z) would seem to be overkill for your title, as I don't imagine there'll be a huge Z range. But you can set it up as you need it (aka just a tiled renderer, though maybe keep the z-binning at least open to future implementation?), and it can provide a unified lighting pipeline, so you can choose (and compare) whether deferred, forward, or a hybrid of both works for your scenes and set up. Hope that helps! ^_^
Deferred texturing 'fixes' the bandwidth problem of deferrend lighting, see https://forum.beyond3d.com/threads/modern-textureless-deferred-rendering-techniques.57611/
MSAA can be used to do this a half resolution to decrease bandwidth even more, with limited API support.
Because deferred anti aliasing has been improoved a lot, and PBR limits the one material problem, it's still difficult to make a decission.
Because deferred anti aliasing has been improoved a lot, and PBR limits the one material problem, it's still difficult to make a decission.
You lost me on this bit here. What do you mean PBR limits the one material problem? Is that a good thing or a bad thing.
On another note, I noticed that deferred rendering makes heavy use of a lot of buffers. Could someone give me a list to consider?
What do you mean PBR limits the one material problem?
It may be debatable, but i think using a general PBR shader for everything should do it and thus the argument of limited material types becomes almost neglectable.
Years ago it was common to use different shaders for different materials and because that's costly for deffered, deffered renderers missed rich material diversity.
I noticed that deferred rendering makes heavy use of a lot of buffers. Could someone give me a list to consider?
Light accumulation RGB
Normal XY
Diffuse RGB
Material properties (specular power and intensity)
Motion vector XY
...
Usually 4 Render targets are used to store all this at required precision.