yeah but the deal is that the walls are lit by them meaning all lights should be in place when the "world" is rendered.

i could be wrong but isnt that 8 lights per pass?? so do 2 passes you can have 16 lights and 3 passes 24 lights, slow but i think it works, im prolly wrong tho

Your "eight lights per pass" only has one problem:

-Render a portion of the screen with 8 lights enabled
-Remember what portion of screen you rendered and somehow preserve it
-Render another portion of the screen with another 8 lights...

This might work, if you have like two areas on your screen with eight lights each... once they start to overlap, better not think about it

One rendering pass will destroy the previous, unless you preserve the results of the previous one. So you''d have to do all sorts of alpha blending or bit masking etc...
The only place I remember ever using multiple passes was with shadow volumes. You have one rendering pass that marks that parts of the screen that are in shadow, then you render the non-shadow part, then the shadow part. This works only because those rendering passes occur in different parts of the screen, and thus don''t cancel each other out. The first rendering pass does not produce visible results, and will do bit masking only.

Plus: two rendering passes, twice the time. Not quite what I''d call "without loosing too much speed" (Must not always be exactly twice, but never faster then one pass).

I haven''t had time to properly try this but,

#define GL_LIGHT(i) 0x4000+i

i''m using an other comp so i''m not sure if that''s the right code, anyway, if you want you could try it

and that should do .. what?

All of the things like GL_LIGHT1 are constants, or rather enum's that are mapped to some kind of number.

There's the enums GL_LIGHT1 - GL_LIGHT8, which would limit you to eight lights. I guess GL_LIGHT1 translates to 0x4000. Since there's no enum for GL_LIGHT9 you can't define a ninth light.

My guess is that what this neat little macro of his will do is map GL_LIGHT(1) - GL_LIGHT(x) to the correct numbers.

Edit: Actually... from msdn

quote:

---

The number of lights depends on the implementation, but at least eight lights are supported. They are identified by symbolic names of the form GL_LIGHTi where 0 <= i < GL_MAX_LIGHTS.

---

Again, going beyond the maximum number supported by your system will make you go back to sw-mode, which is way slow. Games like UT2k3, Quake3, Doom3 have the same limits, and still manage to look great, so, why shouldn't you manage too? One way to give your game a good touch of realism is not by adding more light, but by adding shadow. One thing I miss in almost any game so far.

[edited by - Wildfire on July 4, 2003 10:42:06 AM]

I personally can''t wait to experiment with cell shading :D. Don''t really care about realistic graphics, but more for non-photorealistic ones

Using more than 8 lights per scene is possible. One way is to build up the lighting first, with z-buffering enabled, in as many passes as you need, doing MAX_LIGHTS lights per pass max. Get MAX_LIGHTS by querying GL_MAX_LIGHTS value. Use no blending on first pass and additive blending on all remaining lighting passes. Then blend in your beauty pass as a final pass by modulating it with buffer contents. This will be not all that fast, and over saturation is prone to occur.

Another option on hardware that supports vertex shaders, is to write your own vertex shader that supports the number of lights you need. Assuming you have enough shader instruction headspace, you typically can get much more than 8 directional light sources, or at least a few more point light sources.

Best option is to rethink your design. Do you really need all those lights? As has been said above, just determine the most significant lights and go with that. Now whether you do that per vertex, per poly, per solid, or something more coarse than that is up to you.

well, at the moment i dont need anything but I was talking about an actual part of a game.

You know the way many games do lighting is they render the lighting while making the map. The lighting is just a texture. In Quake III you see no lighting that OGL produces just multitexturing. This makes the level render much faster.