The lighting effects in OpenGL 1.2 (not the shader lighting, mind you) seem to be a little on the lacking side. Not only that, but it seems that with each light you add, the speed decreases exponentially with a constant number of triangles drawn. For instance, in the 3DMark2001 edition, there was a very high polygon carousel that had lights swirling around it. With a single light, the FPS were acceptable on a relatively slow machine (GeForce3, 1.6ghz). However, when 7 more lights were added, the framerate dropped to a dismal 0.5-2.0 fps. Was this performance hit really due to the addition of more lights, or was it possibly due to a hardware/driver problem? In regards to lighting speed, how do programs do per-pixel lighting and shading? Is it all done using the shader language and run on the GPU, or is some of the lighting/multitexturing done on the OpenGL API side? One last question regarding lighting... Do lightmaps use collision detection? Take a snowboarder in SSX3 for example. During the run there are streetlamps that are colored anywhere from orange to pink to blue, and they shine down on the ground and create a little circle of light. From what I can tell, these little circles are nothing more than colored textures on the ground, saving the computation of a lot of lighting per frame. However, when the rider passes under a colored streetlamp, he/she appears to turn that color, as if the light source were a true spotlight. Is this type of lightmap lighting using collision detection and glColorf or is it actually lighting the character, and not the surroundings? Thanks a bunch!

my guess is that the lighting on the environment is static precalculated lightmaps and ps/fs for dynamic, and that the lighting on the moving objects is dynamic (realtime)

Quote: Original post by skyfire360
The lighting effects in OpenGL 1.2 (not the shader lighting, mind you) seem to be a little on the lacking side. Not only that, but it seems that with each light you add, the speed decreases exponentially with a constant number of triangles drawn. For instance, in the 3DMark2001 edition, there was a very high polygon carousel that had lights swirling around it. With a single light, the FPS were acceptable on a relatively slow machine (GeForce3, 1.6ghz). However, when 7 more lights were added, the framerate dropped to a dismal 0.5-2.0 fps. Was this performance hit really due to the addition of more lights, or was it possibly due to a hardware/driver problem?

Lighting can become very very expensive... in most cases, the things that GL Lights do are not required so it is much faster to use a more streamlined solution.

Quote:
In regards to lighting speed, how do programs do per-pixel lighting and shading? Is it all done using the shader language and run on the GPU, or is some of the lighting/multitexturing done on the OpenGL API side?

I believe these are hand-coded

Quote:
One last question regarding lighting... Do lightmaps use collision detection? Take a snowboarder in SSX3 for example. During the run there are streetlamps that are colored anywhere from orange to pink to blue, and they shine down on the ground and create a little circle of light. From what I can tell, these little circles are nothing more than colored textures on the ground, saving the computation of a lot of lighting per frame. However, when the rider passes under a colored streetlamp, he/she appears to turn that color, as if the light source were a true spotlight. Is this type of lightmap lighting using collision detection and glColorf or is it actually lighting the character, and not the surroundings?

It is trivial to do an effect like this. All you have to do is check whether or not the snowboarder is within the area of the light (x distance from the lightsource), if he is, light him up with a glcolorf (or whatever API they are using). You could easily do it without the light decal on the ground

per-vertex lighting is very slow on consumer-level cards because it is expected that games do not waste processing power in lighting. Rather, one or two true dynamic lights are used and the rest in computed in lightmaps/shadowmaps.

The performance drop in the 3DMark2001 example is due to the lack of hardware support. Geforce3's T&L hardware can not handle 8 lights, so a fallback algorithm is performed instead.

Quote: Is it all done using the shader language and run on the GPU, or is some of the lighting/multitexturing done on the OpenGL API side?

Could you please explain a bit more this question ? It doesn't really makes sense to me.

One way of creatong this effect, is to make any static meshes (EG: Terrain) to use a multi-textured lightmap, this can be colored any way you want.

For any dynamic (Moving) Objects, you can project the lightmap onto the model, as a second multitexture.

This idea could do with a lot of improvement, but the basics are sound.

Quote: Original post by skyfire360
In regards to lighting speed, how do programs do per-pixel lighting and shading? Is it all done using the shader language and run on the GPU, or is some of the lighting/multitexturing done on the OpenGL API side?

This is a pure shader program.

Quote: Original post by skyfire360
One last question regarding lighting... Do lightmaps use collision detection? Take a snowboarder in SSX3 for example. During the run there are streetlamps that are colored anywhere from orange to pink to blue, and they shine down on the ground and create a little circle of light. From what I can tell, these little circles are nothing more than colored textures on the ground, saving the computation of a lot of lighting per frame. However, when the rider passes under a colored streetlamp, he/she appears to turn that color, as if the light source were a true spotlight. Is this type of lightmap lighting using collision detection and glColorf or is it actually lighting the character, and not the surroundings?

While i don't really know how SSX3 does this, but i do know how quake3 does it.
Basicly you have a 3d grid that covers the whole game level.
This grid contains the lightvalues at a the center of each grid area, then it is just a simple procedure of looking up the grid value at the current position of the player and color him acordingly.

Thanks for all the replies! I've realized that there is some merit to per-vertex OpenGL lighting, but it is too expensive to put in place for an entire scene.

Vincoof:
I was referring to fullscene per-pixel lighting that is done in, say, Doom3, Unreal3 and Half-Life 2. Judging from the speed of the per-vertex lighting provided in OpenGL, it didn't seem like the lighting used was in fact the calls from the API (glEnable(GL_LIGHT1) etc.) From lc_overlord's post, I guess that most ways of doing per-pixel lighting are done on the GPU in the form of vertex/pixel shaders, without any gl____ calls.

That's true that per-pixel lighting is computed in shaders, but shaders couldn't live without gl* calls.
But in the end I think I've understood your point. Cheers.

Actualy when using PPL (VP/FP or GLSL) you use same (or even more) amount of gl* calls, since you still have to supply programs/shaders with information about light.

Then where exactly does the speed increase come into play? If I light a 10,000 polygon scene with 4 GL_LIGHT#s (per-vertex lighting, not per-pixel), it slows to a crawl. Yet Deus Ex 2, Doom3, Half-Life 2 etc all use per-pixel lighting (which appears to be many, many more calculations) on every object in their scene and it seems to run just as fast - if not, faster - than the per-vertex lighting.