Hello there! I guess, the topic pretty much explains what I´m wondering about. Currently I have implemented a simple deferred renderer and therefore have "evaded" that problem, but I am thinking about implementing a forward renderer, too, and therefore encounter that problem again: If I have a scene consisting of about 60 to 100 objects (only complete meshes, no polygon soup or something like that) and have about 30 lights in the map or something like that, I obviously need to determine which lights should be used to render a certain object, e.g. which lights have the most impact on the look of the object. That "the most impact" part is where I´m having problems. Imagine a scene with an ambient light and a directional light, add to this a big, but not too bright point light and a spot light with a narrow cone and high brightness. Now the ambient light is rather obvious, it should be used for all objects, as well as the directional light, but the other two confuse me: While the point light might light a bigger part of the object, the narrow cone of the spot light might be more noticable, especially if it is neglected for some frames and then pops back in. I admit the example is a bit invalid because four light sources won´t be a problem anyway, so just assume there are many more lights that could affect the object. So, how could an algorithm look like that determines which lights should actually be used?

Why would you have 30 discreet lights affecting any single object? And don't count "ambient" as that's basically a freebie in your lighting shaders.

I'm no quite an expert on shaders, but my understanding is that you can have as many lights as you can pack into the available variables, right? That seems like a decent number of lights.

FYI, the Splash Damage guys said that in Enemy Territory: Quake Wars, they average *fewer* lights than in Doom3/Quake4.

The C4 engine does something interesting; at the load-time for a scene, it calculates all the possible light/surface combinations and creates a unique shader for each. This isn't really all *that* difficult to accomplish and as long as you have nicely discreet "shader blocks" you can easily add new lighting and surfacing techniques.

seems like a misunderstanding.
The problem currently is not how to actually render an object with an "arbitrary" number of lights, the problem is how to find out which of these 30 lights would have the most impact on the object´s look and to use these for rendering later on.

okay, so this is just about finding a suitable "weight function" for some of these parameters like distance light <-> object, luminance and color contribution (and/or other factors that could affect visual appearance if necessary)? I guess it is usually enough to sample that weight function for the center of the object, if the object doesn´t get too big, and perhaps for the vertices of a simpler bounding volume if the object gets bigger?
After that is done I should be able to sort the lights for "importance" to the current object and simply pick the most important ones I guess.
How many lights are realistic to do in one pass nowadays without shadows and with shadow-mapping? I´m using HLSL and intend to support Shader Model 2.0 hardware or better.

I'm doing about 20-30 additive (non shadowcasting) lights on a single object at one time.

Once you throw shadows in there though, things get exponentially more expensive to render.

~Main

Yeah that could get expensive in a forward renderer - no two ways about it. In particular, the computation overhead for finding and sorting suitable lights is nontrivial in a fully dynamic scene.

My by suggestion is to use your bounding volume hierarchy as best you can to get a short list of lights that may affect your object, then sort them by importance (probably a function of distance, priority, intensity, etc). One simple metric would be to compute the light intensity at the nearest point on the BVH, or even the center point.

It's going to be tough to avoid "popping" if you don't use all of the lights though, and anything is in motion. Probably the best solution involves always doing all of the lights that could potentially affect an object, and then getting the level/lighting designer to avoid putting too many lights with overlapping bounding volumes.

If you're not doing HDR, you can probably get away with only doing the few "most intense" ones, hoping that it will push it over 1.0 (and thus get clamped). With HDR you most certainly cannot do this. It also won't work for several less-intense lights.

Anyways there's not really a good solution that I've found. That's just the price that you pay for trying to reduce the geometric complexity of lighting in a forward renderer.

@ElFrogo:
20 to 30 lights without shadows? Sounds like it would be enough.

@AndyTX:
Yes, using the BVH (in my case a simple QuadTree) to cut down the number of lights I have to check more precisely was one of the things I was thinking about. I´m not going to implement HDR but I don´t want to be left hoping that the lighting will reach 1.0 before I "run out of lights" ;)

Perhaps it might work to do the following:
If it is really possible to do 20 to 30 lights in one pass without shadows I should be able to get _all_ lights affecting one object into one pass (I hope I won´t reach 10 lights for one object).
If I can do all lights without shadows in one pass, I should be able to pick the 2 or 3 lights that have the most impact on the whole screen and render them using shadows, right? I guess if I do it right I should be able to use 2 or 3 shadowmaps in one pass (if they´re filled beforehand of course).

So all in all the plan is:
1. Do frustum culling on the scene´s objects, leaving me with visible objects and a bounding volume that contains all visible objects.

2. Do an intersection test with all lights and the visible objects´ bounding volume. If a light intersects the visible part of the scene add it to the list of potential light sources for the current frame.

3. Based on light intensity, distance from the visible scene, perhaps volume of the intersection with the visible scene and things like that choose the 2 to 4 most important lights to the scene and fill shadowmaps for them.

4. Assemble a list of lights for each object containing the lights that affect the object at all. This list will be a subset of the lights surviving step 2.

5. Render every object using the corresponding lights from step 4.

Does this plan sound feasible?