How can I create a lighting engine for BSP geometry in OpenGL?

Question

I am trying to figure out the best way to go about creating a lighting engine for an old game format with BSP based geometry. I have all the relevant information about the light, R/G/B/brightness/radius all that sort. I want to go for per pixel lighting. How can I go about doing this? I have seen tutorials for simple examples like one light revolving around an object but wondered if the same concept applies when having numerous lights illuminating a level.

Also, the BSP geometry does not use lightmaps so that is out of the question.

Also, I am interested in using normal/specular and diffuse maps I generate with Crazybump if that helps influence your advice.

Answer 1

Your main problem is shadows and occlusion. It's simply not enough to light for example an old Quake-level with the trivial point-light-on-polygon model no matter if it's forward or deferred shader (the latter is just an optimization). It works fine for approximately convex objects within the scene, but the interior itself is usually highly concave and filled with occluders.

There is a reason many games including the old BSP-games use pre-computed lightmaps - because then you can raycast every point on every lightmap to every light in the vicinity and get perfect shadows, and you can add a costly radiosity-pass which is also needed to get good realism..

Better then is to do shadow volume rendering but this is indeed costly to do for the static lighting of an entire BSP level - you might have multiple point-lights on every section of every wall! Also it does not handle radiosity. On the other hand, the geometry is very simple in the old BSP-games and renders extremely fast as a shadow volume so it might just work.

A combination of the two is probably most common - you precompute either 2D lightmaps or 3D lightmaps for the static or almost-static lights, then for a few dynamic lights you can use some simple non-shadowing point-lights or shadow volume rendering top of this.. and if you're feeling lucky, you can add some realtime radiosity algorithms like CryEngine3's light volume propagation on top of this.

Answer 2

I'm assuming you want to do dynamic lighting (rather than, say, baking your own lightmaps).

There are plenty of tutorials out there on dynamic per-pixel lighting using normal maps in OpenGL. I've got some on my website; they're a few years out of date, but might still be useful.

The tutorials there use forward shading, which means that you draw the scene geometry and evaluate all the textures and lighting equation in one pixel shader. If you need multiple lights, you have to re-render the scene geometry multiple times, combining them together with additive blending (you also have to include ambient light somewhere along the line). This is relatively easy and quick to code, but can become too expensive for complex levels with lots of geometry and lights. You'll definitely want to use a culling system to get rid of geometry and lights that aren't needed based on what the camera can see in a given frame.

Forward shading can also become cumbersome if you have many different kinds of materials requiring different shading equations (not just different textures), and many different kinds of lights (point, spot, etc.), because every combination of material type and light type requires its own shader.

In cases where forward shading is too expensive or cumbersome, there is another approach called "deferred shading" that has become very popular recently. You can read all about it online, so I won't explain it in detail here; I'll just say that it can be more efficient if you have highly complex scene geometry and/or large numbers of lights on-screen at once, and it often reduces the number of shaders you have to write. However, it's a more complex system and will be trickier to code, and take longer to implement and debug.

Since you said this is an old game I'd guess forward shading may work well enough for you, as the geometry and lighting are likely not that complex by modern standards. Just be aware that deferred shading is a viable alternative.