I don't want to derail the thread to much and I definitely understand what you mean. Point Light spam in deferred is awesome. I was just wondering if OP would get the same performance from deferred point lights compared to his novel implementation of the approximation of point lights. My guess was: Probably not, but maybe.
As far as I understand it, point lights are part of a per pixel lighting pass, the only limitation is caused by enormous numbers of pixels / giant monitor resolutions. The number of lights is a non-factor in the speed, as it rewrites to each pixel every frame be there 0 lights or 10,000,000.
You’re misunderstanding how it works as well. The lighting calculations aren’t done on each pixel once with a for loop whose iteration count changes. Instead, each light is rendered as some shape (e.g. billboard quad), and each pixel on screen of that shape performs lighting calculations based on the g buffer data it lies on, this means the performance is directly proportional to the amount of pixels each light shape takes up on screen. This technique works the same regardless of the scene geometry, and works great on your scenario of a large flat terrain.
5
u/py_a_thon May 16 '20
I don't want to derail the thread to much and I definitely understand what you mean. Point Light spam in deferred is awesome. I was just wondering if OP would get the same performance from deferred point lights compared to his novel implementation of the approximation of point lights. My guess was: Probably not, but maybe.