Thanks, Simon. :)

How do I do additive blending? Is it glBlendFunc (GL_ONE, GL_ONE)?
Do I have to render the shadows for the walls, too?

Quote:Original post by karx11erx
Thanks, Simon. :)

How do I do additive blending?
Do I have to render the shadows for the walls, too?

every light needs to have shadow volumes for all relevant objects, walls included.
however since walls are pretty much static the volumes for those only needs to be updated when/if the light moves

i think it is GL_BlendFunc(GL_SRC_COLOR,GL_ONE); , im not 100% sure though.
just try it and see if it looks right :) , if it doesn't you can try with another blendfunc.

Edit: hmm it could be GL_ONE,GL_ONE aswell, been quite some time since i did this,.. just try and see.

Would shadow mapping be a better method here?

This multipass approach might kill performance for me.


[Edited by - karx11erx on December 5, 2006 10:18:17 AM]

Quote:Original post by karx11erx
Would shadow mapping be a better method here?

This multipass approach might kill performance for me.

Depends a bit on the hardware, shadowmaps are quite slow aswell though, and high resolution shadowmaps eat up vram pretty quickly. (generating dynamic shadowmaps isn't that cheap on low end hardware either).

if you set the number of lights per triangle (or per sub-mesh) to 2 the extra pass is probably cheaper than it is to generate shadowmaps. (the first ambient pass would lay down the z-buffer and the stencil buffer would cut out a bunch of extra pixels aswell, so basically you only push a few extra polygons which is reasonably cheap even on old hardware (such as the GeForce4)

Are there other good shadow rendering methods with both good performance and good looks?

Quote:Original post by karx11erx
Are there other good shadow rendering methods with both good performance and good looks?

not really. its always a trade off.

nvidia has a few documents on developer.nvidia.org regarding both teqniques + advice on optimizations etc.

(multipass rendering isn't as expensive as it sounds as each pass is very limited)

this one might be worth reading.
http://developer.nvidia.com/object/shadow_considerations.html

I am having 50+ lights per scene.

Quote:Original post by karx11erx
I am having 50+ lights per scene.

assuming your scene consists of multiple meshes or can be divided into multiple meshes you could simply select a smaller group of lights for each mesh based on the lights direction, intensity and position relative to that mesh.

a weak lightsource or a lightsource that is far away don't really contribute much to that particular mesh and can thus be ignored. using 4-5 lights for each mesh or sub-mesh should be enough. (depends a bit on how your lights are placed and the size of your sub-meshes)


here is an example that deals with vertex lighting and opengls built in lighting model (which supports up to GL_MAX_LIGHTS in a scene ,it used to be 8 or so if i remember correctly, hardly matters these days though).
http://www.opengl.org/resources/code/samples/mjktips/VirtualizedLights/multilight.c">


it shows you how to calculate how bright a light appears based on object to light and object to eye vectors , light intensity etc.

you may also want to add some culling methods to exclude lights that can't "see" the target object at all.

you could make the number of active lights / sub-mesh a variable so that it can be easily changed to get a good performance/visual balance. (perhaps even let the user set it so that users with high end hardware can waste a bit extra power on getting things "perfect"). with small enough sub-meshes you really shouldn't need more than 4-5 lights though. (small as in surface area, not number of polygons). subdividing polygons to break a large wall into smaller pieces can be a useful thing in these situations.