Maximum Number of lights in OpenGL vs. D3D

Started by
5 comments, last by Truckhunter 23 years, 11 months ago
I have just recently started working with OpenGl, and I noticed that there is a limit to the number of lights you can have in a scene. I checked, with glGetIntegerv(GL_MAX_LIGHTS,numptr) and found that on my win2k system the limit is 8. When I look at the D3D caps structure for lights, it tells me that it supports unlimited light objects. I''m doing my first big 3D project (mostly been doing 2D until now), and it doesn''t use any lighting effects. So obviously this limit isn''t a problem to me. However, it occurs to me that this could become a problem in any large 3D game project. Does this become a problem, or is 8 plenty and I am just not seeing it right now? Is there a way around this? This isn''t an urgent question, but it seems like an argument in favor of D3D. I personally hold no preference for either, and would rather this thread didn''t become an overheated debate between the two. I''m just wondering if the OpenGl light limit is a problem in practice.
Advertisement
that''s lights per vertex i think. you can change the lights i think as you render every polygon. if you have more than 8 lights in a scene, when you go to render some polies, you just want to turn on the 8 lights most likely to illuminate the polies (something as simple as shortest distance, or maybe some minimal visibility check would be a good heuristic).

sorry... continued -- then, while rendering the same scene, you would activate a different set of lights for a set of polies located elsewhere in the scene.
Actually D3D lights are limitied to whatever your hardware supports. I think software mode is unlimited. Still, it should not matter because you should not use vertex lighting.
How do you suggest lighting be donw, then?
Vertex lighting is very useful when the change of light color/intensity over a polygon is not too large. This is because lighting is calculated only at vertex level, and the shading is not perspective correct. This means that in areas where a lot of light intensity variation is present, you need to subdivide your polygons to create more light sampling points.

Another way of doing lighting is through a low resolution texture map which contains the diffuse lighting. This is what is done in most games. Search for articles about lightmappingn, for example, FlipCode (http://www.flipcode.com)

Personally, I use vertex lighting in my new engine, since this frees up a texture stage which I can use for other effects, and the target for the new engine is T&L accelerated boards. But I do have the problems I mentioned before, the non-perspective correctness of the lighting and bad lighting in light/shadow areas.

Take a look at this demo from nVidia. It shows a flat surface lit by 300 lightsources. Obviously every vertex isn''t lit by every light because the hardware only supports 8 lights.

You would probably never need more than 8 lightsources in your calculations even if the hardware supported it. Most of the time you can simply omit most of the sources in your calculations because their contribution to the endresult is so small that it wouldn''t matter anyway.

For vertex lighting you should divide your scene into small enough pieces then when rendering each piece you only enable those lights that matters the most for that particularly piece. Usually it is the lightsources with the least distance, but also the lights angle with the surface normals matter, if the angle is large the contribution will be small. If you do it this way you''ll be fine with just 8 hardware supported lights.

For those interested, the demo above comes with sourcecode. (Sorry, DirectX only).



- WitchLord

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

This topic is closed to new replies.

Advertisement