I've coded in lightmapping into my opengl game. Currently all lights are static, so lightmaps for all the surfaces are generated at start up. I intend to use dynamic lighting as well, such as torches, explosions etc. What is the best way of optimising this? If I generate the dynamic lightmaps every frame isn't it likely to slow down the frame rate? Should I keep the static lights and then render another (dynamic) light map on top of it when rendering? It just seems like it could really slow things down

Is this a 3D game?

How do you intend to implement dynamic lights?

Can you just use the built-in lighting features of opengl for dynamic stuff? Set a point light on the explosion? That'll be a lot faster, certainly, and explosions are usually long enough that shadows are important for effect, at least during gameplay.

If the torches are themselves static, and can just be on or off, you could also make a system for switching lightmaps based on the torch configuration, although with enough torches that could get memory-heavy.

The way the polyengine does it (which I'll release an AllegroGL-based cross-platform version of soon), is that it keeps around the static lightmaps in RAM, and when a dynamic light is added to it, it's copied to a temp buffer with the new light added on top, then uploaded to a temp texture in the card, and blended onto the poly.

So basically what happens is this. A lightmap face is marked to have a dynamic light on it if a lightsource is close enough. All polygons (except translucent/transparent ones) are drawn, then the lightmaps on those polys. If a visible lightmap is marked to be dynamic, it's skipped, and added to a list. After the static ones are all done, a temp OpenGL texture is selected. Then for each dynamic lightmap in the list, the original static lightmap is copied to a temp RAM buffer and the dynamic light is blended onto it, where it is then uploaded to the temporary texture (via glSubTex2D) and displayed as normal.

In this engine, each poly face has its own unique lightmap (ie. they're never reused between two different poly faces), so each lightmap can be held in RAM with its own x/y/z/u/v coordinates. If your engine differs.. then you'll either have to modify that method, or make up your own based on something like that.

It's things like this why vertex and fragment programs were invented. Feel free to use them.

If you're, for whatever reason, targetting hardware that doesn't provide such features, I wouldn't bother with dynamic lighting. It isn't worth the effort. Just stick to lightmaps and you'll be fine.

It wouldn't be hard to support both, would it? If there's multitexturing, draw the polys and static lightmaps, else do it two-pass as I detailed above. If there's vertex/fragment programs use them for dynamic lights, else do it with multitexturing, or two-pass.

I don't know for sure, but that just sounds really slow. Couldn't you do something with vertex normals to get an intensity of the dynamic light color and then use glColor3f() to apply it to the smooth shaded vertex/texture?

No, because there isn't any vertex lighting in a typical lightmap engine. And it's not really that slow since, at least for Quake 2, a lightmap for any given surface is no bigger than 16x16, and it is stretched to a 32x32 (maybe 64x64) area. With linear interpolation, the decreased resolution is barely noticeable, especially since there's a full-resolution texture underneath it.

Ugh.

These are two fundamentally different ways to think about rendering. One method needs to constantly provoke state-changes, thus destroying performance.

The program method can be done easily enough such that it work with the hardware, not against it.

It's better to have more interesting geometry than to have very basic geometry and lighting.

I understand that. But for cards that can't handle the vertex and fragment programming, how else would you do it? Just disable it even though they're capable enough?

Yes. The polygon count and texture work is more important than dynamic lighting.

Most games look better with lighting than without it.

No, but if it causes massive FPS drop make a way to disable some things. For example amount fo FPS isn't very important for me unless it's really low.

thanks for the feedback on this post. I've been playing around with a few things and probably going to do as suggested and render three layers: the texture layer, static lightmap and then (if necessary) dynamic lightmap to each surface.
I thought you might be interested in how its turned out so I've attached a screenshot
It just shows a light in a corner of a room. The screen dump turned out incredibly dark for some reason. I edited the brightness which is why the colours might seem a bit odd.
I've tried using the opengl lighting before, and found that it generally sucks. I've also tried doing as nonnus suggested by setting an appropriate colour to each vertex of the surface, but this is only effective for small surfaces. for example, if you have a large wall with the light source torwards the middle of the wall, the wall will end up being darker than it should be.

edit: I also attached another screen to the original post

Hey James, when is your next demo coming out?

its going to be a while yet, because I started completely re-writing my game. I also have A level exams coming up over the next month so will spend quite a bit of time revising. When I've implemented proper clipping, skeletal animation and rigid body physics I'll probably upload a demo. The skeletal animation / rigid body physics are going to take quite a while. I've done them before though so I know what I'll be doing. Its gonna kick ass to have ragdoll!

awww, oh well. I can't wait for the demo, it's like waiting for HL2...in the good way...not the lying, tricky way...