10 replies to this topic

[Telios]

Hiya,

I've not looked at much graphics programming for a couple of years. I remember when deferred rendering was first used, it had some problems relating to the number of render targets supported and fill-rate (iirc) and needed fairly high-end hardware to be acceptable.


Is deferred rendering now a suitable choice for more casual games, where the player might not be expected to have the latest hardware?



I'm assuming that most low-end nVidia or ATI cards can handle deferred rendering nowadays. How about integrated cards such as Intel HD or the Intel GMA series?

Thanks for any advice

Cheers.

[jischneider]

The hardware limitations were diminished with Deferred Lighting, an alternative that uses less render targets (especially at the same time) that Deferred Shading. Most console games uses deferred lighting partially because of this.

Bye!!

[Telios]

Thanks!

Hmm, that's very interesting - this is the first time I've heard of deferred lighting. I'll have a trawl for more information.

Any links would be appreciated

[jischneider]

Some time is mentioned as Light Pre Pass.
http://www.insomniacgames.com/tech/articles/0409/files/GDC09_Lee_Prelighting.pdf
http://www.slideshare.net/guest11b095/a-bit-more-deferred-cry-engine3
LightPrePass.ppt (search in google)

If you need an implementation (XNA only sorry):
Tutorial: http://mquandt.com/blog/2010/03/light-pre-pass-round-2/
Tutorial2: http://roy-t.nl/index.php/2010/12/28/deferred-rendering-in-xna4-0-source-code/
My engine: http://xnafinalengine.codeplex.com/

Good luck!!

[Telios]

Brilliant, thanks!

[jischneider]

You're welcome!!

[AgentC]

Intels from HD onward should be able to handle deferred shading or deferred lighting fairly well, if the graphics overall aren't too complex (though, the same would apply to forward rendering.) GMA 3xxx & 4xxx can theoretically do deferred, but you'll likely find the raw performance lacking. GMA 950 and co. cannot render to multiple render targets, and only support rendering to RGBA8 textures, so you would likely need a fallback-path, and the performance would be abysmal anyway.

Note that deferred lighting requires to render the scene geometry twice, so depending on the scene you may become drawcall and vertex bound, while not winning that significantly in bandwidth. On consoles (of which I have no experience) the performance picture may well be different.

[jischneider]

Note that deferred lighting requires to render the scene geometry twice, so depending on the scene you may become drawcall and vertex bound, while not winning that significantly in bandwidth. On consoles (of which I have no experience) the performance picture may well be different.

This is completely true and is probably the main disadvantage of deferred lighting. Also, I remembered a good article in Shader X7.

Bye.

[MJP]

Yeah light prepass/deferred lighting is usually not so great on PC due to the possibility of doubling your draw calls. Of course you can also get into the same situation if you want to do an z-only pass before laying out your G-Buffer in a traditional deferred renderer. Usually the best case for deferred lighting is when there is a disproportionate rendering cost associated with using too many render targets, which is certainly the case for 1 of the consoles but not for most PC hardware.

[Hodgman]

On any DX10 compatible hardware (including recent Intel chipsets), I would assume that deferred shading / deferred lighting will be able to be implemented with decent performance.

[Telios]

That's great, thanks for all the info. +1s for all

Intels from HD onward...

Brilliant, exactly what I need.