Archived

This topic is now archived and is closed to further replies.

Spongemop

Eight GL_LIGHT limit

Recommended Posts

8 lights per polygon.

You can set those lights anywhere at any time.

Apply the 8 closest light effects to each object you are rendering, and the effect should be good enough.

Share this post


Link to post
Share on other sites
While a level may have more than eight lights, it''s fairly rare for it to have eight lights that are significantly affecting a particular object simultaneously. Just pick the eight lights with the greatest localized brightness (absolute brightness / distance2) and use those.


How appropriate. You fight like a cow.

Share this post


Link to post
Share on other sites
I always thought 8 lights is the minimum for hardware implementation. But thus far, no company increased it. But with programable pipeline, you can increased it yourself, I guess, it will be slow though.

Share this post


Link to post
Share on other sites
If I''m not mistaken the number of max. lights is hardware dependant. There''s something like GL_MAX_LIGHTS (or similar)that''ll tell you how much hardware accelerated lights your card supports for one surface.
If you go beyond the number your (or somebody elses) hw supports you''ll ''just'' drop back to software, which will be significantly slower of course.
As Senftel said, if you got a 3D level with several rooms, you just have to make sure that no more then eight lights are visible at once. Only glEnable those lights that truely have an effect on the player at it''s current location and glDisable the rest.

Share this post


Link to post
Share on other sites
Then Im curious about this:

I was playing Zelda on the cube yesterday, in the forestpart, and there were green orbs (or whatever) flying around everywhere, and they all had their own light, with a small radius though (i guess somewhere around 1.0f, really small) that showed up when they got close to walls n stuff.

What would be the best way of achieving a similar effect? (without loosing too much speed)

Share this post


Link to post
Share on other sites
My guess would be:
a) The gamecube supports more then eight lights simultaniously. As mentioned before that''s hw dependant.

b) They use a clever trick, so that no more then eight spheres are close to a wall same time, and thus require lighting effects.
(Or at least no more then eight of the visual spheres to that...)

c) The used some kind of multi texturing. A small texture that looks like a ''lighting glow'' gets blended over the floor/wall texture, and is scaled according to the spheres distance.

Now, get started

Share this post


Link to post
Share on other sites
lol, get started. Right now i''m working on a really good Framework, which can use openGL, or whatever you want it to use. At the same time I''m writing a series of tutors about that for www.maxcode.com. Just finished part one (still have to convert it to html though) Part one features:

- Creating a new project

- Creating and initialising the program

- Proper error-handling

- Adding the ability to log to a text file

- Adding the ability to change the display mode


Part 2 will handle creating windows.
Part 3 will handle deriving a gamemode-class from part 2, which will be able to use openGL or other libraries, but i will base it on using openGL
Part 4 will actually do ... something with openGL, but nothing big since im still pretty new to openGL itself

Share this post


Link to post
Share on other sites
U can do many lights at one go as long as a polygon is not affected by 8 lights at 1 time.

Like the Zelda example, u could do it this way.
Say u have a Green light.

GreenLight.pos={x,y,z};
RenderOrb1();
GreenLight.pos={x2,y2,z2};
RenderOrb2();
etc...
And you only use 1 light this way!

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
so how do those work? just a quad that stays alligned with its object? then how do they make the light hit 2 zones like this? :

side view:
------------------> |
--------------> =====
--------------> |


but is this the idea? :

top view:

. -
| o |
. -

| and - symbolise quads. o is an object emmitting ''light''

Share this post


Link to post
Share on other sites
Q3 uses the OpenGL lights for models. Only static geometry is lightmapped.

quote:
Original post by Wildfire
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.



What on earth are you talking about?

The only time a pass will destroy the previous contents of the framebuffer is when the blend state is set to ( GL_ONE, GL_ZERO ). Ie, blending is disabled. Or, when you use standard alpha blending and everything has a full alpha.

Learn what you''re talking about before you start to spread mis-information.

For instance, lets see how you can apply a shadow map to a scene, in a two pass fashion. In the first pass, you''d set the blending state to GL_ONE, GL_ZERO, and render the decal texture. For the second pass you''d set the blending state to GL_DST_COLOR, GL_ZERO ( a modulation ), and render the shadowmap. Now, at no point does the second pass destroy the first. No stencil buffer is used.

Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites
quote:

The only time a pass will destroy the previous contents of the framebuffer is when ... blending is disabled.



Which is exactly what I said:

quote:

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 [in order to preserve/use the previous frame buffer content]



I just put it the other way round.

And, as far as I know, blending is disabled by default in OGL.

So, again, any rendering pass that produces visible results will destroy the previous one, unless you enable blending or use the stencil buffer, or other means of preserving previous frame buffer contents or mixing them with the new ones in some way or the other (most likely blending of some sort).

I have implemented both shadow volumes with one and multiple light sources, so I think I know a bit about multiple rendering passes and using the stencil buffer/alpha bleding (w. extensions) to produce a final visible output.

[edited by - Wildfire on July 5, 2003 10:55:07 AM]

Share this post


Link to post
Share on other sites
Ok.

Still, there are far more applications of multipass rendering than shadow volumes. The way you said that the only thing you''d used multipass rendering was for your shadow volumes implied that it''s hardly ever used, and isn''t used for much. This made me think that you didn''t know what you were talking about.


Death of one is a tragedy, death of a million is just a statistic.

Share this post


Link to post
Share on other sites