GL_LIGHTx

Does the specs ensure that GL_LIGHT0 + 1 = GL_LIGHT1 and so on ? If yes, and if an implementation supports more than the 8 default lights, do the next lights (GL_LIGHT8…) follow the same rule ?

(if this does not stand in the advanced forum, please move it to the appropriate one, thanks).

Yes, GL_LIGHTi == GL_LIGHT0 + i.

But this works only up to GL_LIGHT7. I don’t think it’s possible for any implementation to have more than 8 lights using the fixed function pipeline, you’d have to use shaders and/or multipass to do that…

What do specs have to do with hard-coded constants?

Look in your gl.h header file:
#define GL_LIGHT0 0x4000
#define GL_LIGHT1 0x4001
#define GL_LIGHT2 0x4002
#define GL_LIGHT3 0x4003
#define GL_LIGHT4 0x4004
#define GL_LIGHT5 0x4005
#define GL_LIGHT6 0x4006
#define GL_LIGHT7 0x4007

Originally posted by Overmind:
[b]Yes, GL_LIGHTi == GL_LIGHT0 + i.

But this works only up to GL_LIGHT7. I don’t think it’s possible for any implementation to have more than 8 lights using the fixed function pipeline, you’d have to use shaders and/or multipass to do that…[/b]
The specification requires at minium 8 lights to be supported, but there’s no upper limit on how many an implementation is allowed to support. Light N can always be referenced by GL_LIGHT0+N, no matter how many lights are supported. Only the required 8 lights have predefined names though.

Originally posted by Overmind:
to have more than 8 lights using the fixed function pipeline, you’d have to use shaders and/or multipass to do that…
you will have to use shaders AND multipass because extending GL internal lights parameters buffers/table doesn’t look so trivial for me…
Maybe i’m wrong but most implementations are limited to 8 lights and there is no known way to access/store more informations than this as it is not an opened part of the api and has certainly been compiled using the GL_MAX_LIGHTS limit for lights params buffers.

Now you’re free to implement your whole multipass lighting stuff and it’s definitely the new fashion way of lighting :wink: as you wish… ^^

As a conclusion, gouraud based lighting using 8 opengl lights is most of the time far enough if you don’t consider these lights as 8 globals lights in your world but as 8 local lights which can be binded in many clusters of your world :slight_smile: then you got into your hands a kind of infinite lights combinations :slight_smile:

Thank you all.

I think you can simulate plenty lights with only 3 or 4 real GL lights, without doing multipass at all. That’s not what this topic was for, but as some discussed of it, why not talk about that too.

Let’s say you’re in a building (like a skyscrapper), you won’t have to make all the lights for all the flats and all the corridors: it would be about thousands lights, it’s simply non-sense, even if you look at it from outside and quiete far. You’ll just use as much light as necessary for the location where you are.
If you’re inside a flat, just use as much light as necessary for the room where you are and the other rooms lighting up this room (the ones with open doors and so). And when you leave your flat, accessing the corridor, then, only at this moment you may have more lights, but only until you close the door. Then you’ll be able to recycle your old flat lights.

Hope that’s understandable.

tibit, you didn’t understood what I was meaning I guess. One single gl header cannot prove that all the lights will have the same values in other any headers (specially from other vendors). Neither it can prove that all the values will be 1-incremented of the previous ones. This is why I was asking that.
And what do specs have to do with hardcoded values ? Well simply because I do not want to use defines in my program, and I’d like not to use GL_LIGHTx neither. And I have to count how much light are in used at a certain time, in an application, and know which of them are free, which one not and so on.

In the MSDN Library I have found the following:

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.
And this:

It is always the case that GL_LIGHTi = GL_LIGHT0 + i.
Strange, but the opengl spec does not mention it.
However, here is the solution. The GL_LIGHTi values are resolved at compile time and are not vendor-dependent. By a vendor I mean a particular library implementor - like NVIDIA or ATI. By a “vendor” you actually meant a platform, I think. So, if you dont believe the documentation, you can use the following code:

 const GLenum LIGHTS[] = {
GL_LIGHT0, GL_LIGHT1, GL_LIGHT2, GL_LIGHT3,
GL_LIGHT4, GL_LIGHT5, GL_LIGHT6, GL_LIGHT7
}; 

And then, to access i-th light you do:

 glLightf (LIGHTS[i], ...); 

Originally posted by mjkrol:
[b]

 const GLenum LIGHTS[] = {
GL_LIGHT0, GL_LIGHT1, GL_LIGHT2, GL_LIGHT3,
GL_LIGHT4, GL_LIGHT5, GL_LIGHT6, GL_LIGHT7
}; 

And then, to access i-th light you do:

 glLightf (LIGHTS[i], ...); 

[/b]
You don’t need to do this. I’m not sure where it is specified exactly, but you are guaranteed that the enumerants are always exactly the same, namely 0x4000+i for GL_LIGHTi.

If you think about it, this has to be true, because programs compiled with the header file of one implementation have to work with all other implementations.

Originally posted by Ozzy:
As a conclusion, gouraud based lighting using 8 opengl lights is most of the time far enough if you don’t consider these lights as 8 globals lights in your world but as 8 local lights which can be binded in many clusters of your world :slight_smile:
I’d say that’s an example where I concentrated too much on answering the question without thinking about what I was writing :rolleyes:

Of course it doesn’t make much sense to emulate fixed function lighting with multipass and shaders just to get more light sources. And when implementing a more complicated lighting equation using shaders, the problem with the constants is not a problem anymore :wink:

Strange, but the opengl spec does not mention it.
Yes it does. p64 of glspec20.pdf

If you have GL_LIGHT1 to whatever defined in your header file, you are lucky.
If you need more, just add them yourself.

tibit, you didn’t understood what I was meaning I guess. One single gl header cannot prove that all the lights will have the same values in other any headers (specially from other vendors).

You’re right. I have absolutely no idea what you mean.

By a vendor I mean a particular library implementor - like NVIDIA or ATI. By a “vendor” you actually meant a platform, I think.

Are you saying GL_LIGHT0 is defined differently on a Mac?

OpenGL “enums” are platform independant. (There’s only one official glext.h)
To handle the nth light you just do GL_LIGHT0 + n.
(And you WANT to use the enum in your code to make it clear to anyone what you’re doing.)

Originally posted by tibit:
[b] [quote]
By a vendor I mean a particular library implementor - like NVIDIA or ATI. By a “vendor” you actually meant a platform, I think.

Are you saying GL_LIGHT0 is defined differently on a Mac?[/b][/QUOTE]Of course not. The enumerants are the same in the all gl headers on the planet. The SGI takes care of it. Your first reply, tibit, got the point.
But since jide apparently does not understand some things involved in building an executable, the conversation had continued. If he does not believe in some facts, we can behave as if it was true and give a solution from that point of view.

Originally posted by tibit: Are you saying GL_LIGHT0 is defined differently on a Mac?
It’s probably not. But it could be. My gl.h says Copyright Microsoft Corporation. So it’s definitely vendor dependent. Of course it has to conform to the specs. Which only says that GL_LIGHT0 + i == GL_LIGHTi. That’s the specification. It’s guaranteed to work. Why peek at ugly header files instead??

Originally posted by andras:
[quote]Originally posted by tibit: Are you saying GL_LIGHT0 is defined differently on a Mac?
It’s probably not. But it could be. My gl.h says Copyright Microsoft Corporation. So it’s definitely vendor dependent. Of course it has to conform to the specs. Which only says that GL_LIGHT0 + i == GL_LIGHTi. That’s the specification. It’s guaranteed to work. Why peek at ugly header files instead??
[/QUOTE]The header says Microsoft because the header is from Microsofts implementation. But that doesn’t mean Microsoft can pick whatever values they like for the constants. The specification decides the name of the constants, and SGI I believe allocates the actual values. All implementations must use the same values.