How can I implement fast lighting with multiple lights?

I don't want to restrain the player, he can place an unlimited number and possibly overlapping (point) lights into the level.

The problem is that shaders which contain dynamic loops which would be necessary to calculate the lighting tend to be very slow.

I had the idea that if it could be possible at compiletime to compile a shader n times where n is the number of lights. If the number n is known at compiletime, the loops can be unrolled automatically. Is this possible to generate n versions of the same shader with just a different number of lights?

At runtime I could then decide which shader to use for which part of the level.

  • \$\begingroup\$ If the lights are added dynamically by the player, how can a "compiletime" shader be the correct answer? \$\endgroup\$ Commented Oct 18, 2013 at 12:52
  • \$\begingroup\$ As I wrote, the compiler could generate shaders for 1,2,3,..lights and at runtime I could decide which one to use for which portion of the level \$\endgroup\$
    – codymanix
    Commented Oct 18, 2013 at 13:06
  • \$\begingroup\$ compile time shaders need to know where the lights are going to be placed, any dynamicness of the lights will ruin them \$\endgroup\$ Commented Oct 18, 2013 at 13:18
  • \$\begingroup\$ only the number of lights should be dynamic. the positions will be provided as parameter. \$\endgroup\$
    – codymanix
    Commented Oct 18, 2013 at 13:28
  • 1
    \$\begingroup\$ It sounds like you have your answer. You know the maximum number of lights and the range of possible positions. \$\endgroup\$
    – ashes999
    Commented Oct 18, 2013 at 16:45

1 Answer 1


I believe what you are looking for is called Deferred Rendering. It is a rendering technique that scales extremely well with a lot of lights, so well that it can used for dynamic indirect illumination. That means 1000s of lights on the screen.

It is basically a technique in which you first render all your geometry data(position, normal, depth) into an intermediate pixel buffer(called the G-Buffer). Then in a second pass you render a light shape along with its parameters. The shader of this second pass takes the information from the G-Buffer, applies light calculation, then blends it into the final image.

You can find implementation details here


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .