Hi, I have a question about light.
The number of lights used simultaneously in opengl is limited. But how can I use unlimited light source in application such as a game?
The idea I can image is to calculate the light myself and blend it to the material, but I am not very sure the practical method used in today’s game.
I have hear something like lightmaps. I want to know more stuff about lights. Any net address or Direction?
Thanks.
To get more than 8 opengl lights all you have to do is just reuse them. Lightmaps dont use opengl’s lighting code at all. Its just an extra texture that is modulated on top of your base textures to give the illusion of a light being there.
-SirKnight
Thank you, SirKnight.
But as your answer, what I want to know is no other than how to calculate this “extra texture” colors and other parameters, so I can completely unlimited light sources numbers in a scene.
Clusterisation is the only way to go!
as SirKnight said, u must reuse the lights!!
All that means that your scene must be subdivided in some parts/blocks and then u can get 8 lights available for a portion of the scene… thus, this makes ‘virtually’ unlimited lights for your scene… In fact, most of the time (in a cluster) 2,3 lights are enough… Of course u can use more lights than this but it will certanly slow down your rendering!! :))
As a conclusion, 8 lights are definitely enough and it was a good choice to do so in the OpenGL implementation bcoz you’re forced to find out the best case and then only encapsulate the vertice which should be lighted by a defined light.
Here’s source code and an explanation of this:
http://www.opengl.org/developers/code/mjktips/VirtualizedLights/VirtualizedLights.html
Thank you, dorbie.That’s what I am trying to find.
Also, thank you Ozzy and SirKnight, but I think eight lights is far less enough to render a “really realistic scene”.|-)
Regards,
Zw
If you really want more than 8 dynamic lights on a surface at once, you can use multiple passes. You can do eight lights per pass – you add all the lighting passes together first, and modulate with the textures afterwards.
It adds up to one pass per eight lights, plus one for the textures. Specular lighting further complicates the matter, but it’s still pretty easy to do.
– Tom
Hi, Tom Nuydens
Let me try catch on your idea. Do you mean to accumulate the lights effect and modulate it with the textures at one time. And again and again to repeat it on the each new material color until numbers of lights I want reach?
He means a first pass which draws 8, then subsequent passes, each of which can add another 8 lights and they are accumulated in the framebuffer with a glBlendFunc(GL_ONE, GL_ONE).
Zw, maybe you did not fully understand that 8 lights is the max for a single poly in your scene. That means 8 lights simultaneously, so you have to know which poly is lit by which light.
Suppose you have a ground split into 4 meshes, and each part is only lit by 7 different lights (that’s 28 lights), then when rendering the first part, you only need to activate the corresponding lights. When rendering the 2nd part, you’ll reuse the old lights and reassign some new values to make them correct for your 2nd ground mesh. And so on …
Hope this helps a bit, Lolo
Hi,
Lolo, what can I do if I want to see all of 4 meshes which lit by 28 lights at the same time in same scene?|-)
This is what Tom was trying to tell you. You draw the same mesh multiple times with 8 lights each time and add them together in the framebuffer with the blend function I mentioned in my post.
28 required lights / 8 available lights = 3.5
So you need to draw the scene 4 times.
The first time you draw as usual with the first 8 lights. Next you draw with glEnable(GL_BLEND) and glBlendFunc(GL_ONE, GL_ONE) and another 8 lights. Don’t depth clear but keep depth testing on. You repeat with another 8 lights, then you repeat again with the final 4 lights.
This will produce a scene with 28 vertex lights. If you use texture the clamping will be different but this will enhance the appearance of the scene IMHO.
[This message has been edited by dorbie (edited 01-15-2002).]
Hello,
Dorbie.Thank you much for your more explanation.I see what to do.
Best Regards,
Zw
Should work… but sounds like a pretty heavy (brutal) technique… 
Hum … I was thinking of a very more simple approach, which was :
1/ Activate Corresponding Lights
2/ Render Mesh 1
3/ Activate Corresponding Lights
4/ Render Mesh 2
5/ Activate Corresponding Lights
6/ Render Mesh 3
7/ Activate Corresponding Lights
8/ Render Mesh 4
9/ Flush
The 4 meshes are separate, each lit by differente lights (but more than 2 for each) so this makes the number of lights > 8 and all is rendered in a single pass
dorbie, could you clarify something for me? While reading another thread concerning OpenGL invariance you mentioned that when doing multipass you would need to use glPolygonOffset to ensure there was no z-fighting. Yet in this thread where you demonstrate a multipass method you don’t mention anything about polygon offset, why not? Did you just fail to mention it, or did you not on purpose (i.e. because its not needed)? It just confuses me since now I’m wondering when I should use polygon offset.
[This message has been edited by DFrey (edited 01-15-2002).]
I don’t think you really need more then 8 Lights per poly, only if you have very large polys, and are using per pixel lighting.
And if you need more lights you shouldn’t render the scene multiple times, it would kill your performance because of Fillrate and transformations. You should do the Lighting by hand for each vertex and then render the scene without opengllighting but with color per Vertex instead.
If you wan’t to use hardware accelerated lights on geforce3 or anything else with vertexshaders, you can write a vertexprogramm which supports more than eight lights (there is an example in the nvidia sdk).
Lars
Lolo, this has already been suggested, I pointed to sample code earlier in the thread which does this. The question about >8 lights on individual primitives arose.
DFrey,
you are correct, I was deliberately keeping it simple.
An offset is the safe thing to do, in the other thread we knew the guy had an offset problem.
Actually what I’d do is perform the first pass with depth writes, then offset but disable depth writes. Even though the subsequent passes don’t necessarily change state, it’s good practice incase they ever do through future modification. I wouldn’t expect different light count to affect z fragments, I’m unclear on whether this might ever make a difference and no depth writes avoids continually having to increase the offset value. Blended vs unblended certainly represents a risk, albeit a small one.
I’d still suggest not using polygon offset for most multipass algorithms. If you only change states like depth parameters, blending parameters, alpha test parameters ( these are listed under strongly suggested in the GL spec ), then it will probably work on the majority of hardware.
I think it’s better to be practical - dorbie already said that polygon offset was made a mess of by OpenGL implementors. Instead of testing various values for polygon offset on a wide variety of hardware ( it does differ ) then why not just make sure that the implementation can handle the strongly suggested states that are listed ( if Quake3 engine games run, then it’s probably fine ).