light objects

[zen]

This is not exactly a suggestion for a future version, rather a question wich has been bugging me for a few days and I suppose this is the place to ask it.

Is there a technical reason why although OpenGL used the object approach to handle multiple textures (introduced into the core in version 1.1 I believe?) it stayed with the fixed state approach for lights? I mean with textures you can define as many objects as you please (until you get out of system ram and swap space of course) and can use any subset of them in a particlar scene/frame. You don't get any guarantees that the HW will support all the textures used during a singe frame (you may get thrashing etc.) but the driver will do its best.

Lights present a similar situation, don't they? Sure you may not be able to render with more than a few of them simulataneously in most cases but a given environment may have quite a few of them. Think of a big house. Each room may have one or two lights so on the whole you end up with a bunch of them but mostly one or two will be visible simultaneously. So to handle such a scene I would have to implement the light management myself mapping the visible lights for each frame to the GL_MAX_LIGHTS available "light objects". Ok it probably isn't very hard to do but it bugs me that although all objects (textures, programs, sounds and buffers(openal)) are handled by the various underlying apis I still have to write code to handle lights. If I would have to write a complete object mangagement module that would be a different thing but having just light object management code in the renderer seems annoying. Wouldn't it be better to be able to do glGenLights a few times, then glEnable or glDisable them accordingly, and finally glDeleteLights them? I believe it wouldn't be much wotk for the driver either, so why don't we have anything like this?

[MikeC]

So far, the motivation for object-based APIs in OpenGL has been to allow drivers to manage large chunks of data - textures, geometry and the like - more efficiently than a procedural approach could do. More generally, as we're seeing with shaders, objects are used to encapsulate renderstate with a high setup cost.

Lights don't really fall into this category; there's no significant quantity of data involved. If the bulk of OpenGL moves to the object model you might be able to make a case for objectifying lights too just for consistency, but I doubt it. Lights these days are just one application of shaders, rather than a major concept in their own right. I imagine that glLight and friends will be deprecated at some point.

[zeckensack]

Light position is more akin to vertex data than to a fixed, object encapsulated state, because it's affected by current matrix state at the time of specification. This is just a minor gripe, and could certainly be worked around.

Note, though, that you can already create arbitrary "state objects" by just using display lists creatively.


So to handle such a scene I would have to implement the light management myself mapping the visible lights for each frame to the GL_MAX_LIGHTS available "light objects".You'd have to do the same with light objects, too. In line with your texture object comparison, you can have an arbitrary number of texture objects at a time, but the maximum number of simultaneously bound objects is limited.
GL_MAX_LIGHTS would limit the number of available light object binding points, just like GL_TEXTURE0_ARB ... GL_TEXTURE3_ARB are the binding points for quad texture implementations.

[zen]

Lights don't really fall into this category; there's no significant quantity of data involved. If the bulk of OpenGL moves to the object model you might be able to make a case for objectifying lights too just for consistency, but I doubt it. Lights these days are just one application of shaders, rather than a major concept in their own right. I imagine that glLight and friends will be deprecated at some point.
You're right. Objects are currently used in opengl to allow the driver to manage the caching of large chunks of data but that doesn't meen that managing small chunks of data isn't useful. Actually from a more theoretical point of view it seems to me that the purpose of objects is to encapsulate "dynamic state", that is state wich gets added to the GL at runtime.
Initially (v1.0) the GL was purely static: just some texture state which you had to change (via display lists usually) to change the active texture. The case was the same for lights although one piece of state wasn't enough for lights even then so you had GL_MAX_LIGHTS pieces. When this wasn't enough the solution used was to be able to add state to the GL on the fly. Each time you call glBindTexture with a free name you create new state on the fly wich the GL then handles. Lights seem to have been left out although it seems to me that from this point of view they're very similar to texture objects, beeing dynamic state.



Note, though, that you can already create arbitrary "state objects" by just using display lists creatively.

.
.
.

You'd have to do the same with light objects, too. In line with your texture object comparison, you can have an arbitrary number of texture objects at a time, but the maximum number of simultaneously bound objects is limited.
GL_MAX_LIGHTS would limit the number of available light object binding points, just like GL_TEXTURE0_ARB ... GL_TEXTURE3_ARB are the binding points for quad texture implementations.
My problem is not that I can only bind 8 lights at the same time although even this is anoying if it's not caused by some hardware limitation but rather by the fact that we have to "draw the line somewhere" since we're using fixed state. But with textures all I have to do is determine the textures used in a frame and enable them at the right time. With lights even though I may only need two given lights enabled per frame I still have to implement some fairly complex logic to map these two lights to an integer between zero and GL_MAX_LIGHTS using as little state changes as possible. With dynamic light state (light objects) I could define state once for all lights and then during each frame only some enabled bits would have to change wich is the absolutely necessary.