serious lighting

[LastBoyScout]

Hi,

there was a thread about lighting and someone asked wether opengls build in lighting is obsolete or not: There wasn't a straight answer and I am not sure now:

Should lighting be done with some custom shader program? (I didn't go into this yet.) Or is glLight ok?

Up 'till now I have an octtree to find the visuals I have to render. My visuals are in the leaves. Recently I started to add lighting to my renderer and of  course the first thing you come across is the limitation to 8 light sources.
So what I did is: Every node has a list of all lights that want to shine inside that node. There is also an 8 element list with the 8 "most important" lights for each node and those are the ones that will be activated when that node is rendered.

With the lightless version my simple test world rendered smoothly (I am keeping the fps at 35, but I get a statistics about the load and the number of missed frames.)
Now since my light handling is in effect things are not so smooth anymore. From time to time it misses some frames (load is still "zero").

Is it possible those load spikes (missed frames) are because I have to reset lights for every visible octnode?
How slow are those state changes?
And if they are so slow: How could I possibly render a scene with many lights anyway using glLight?

Say if I want to have about 100 dynamic lights in my visible area (but not overlapping to much, so 8 activated lights per object is ok): Is that feasible using glLight?

I did google and go throu this forum but I am still not sure about the hole thing.

What can you tell me?

thx
LastBoyScout

[Fool Running]

Even if you did the lighting with shaders, you would still use glLight(). The shaders just would affect how the lights are calculated. The 8 lights are a hardware limitation.
You might check to see how many lights are enabled when you draw a node. Usually having 8 lights on at a time slows down rendering considerably.
Switching lights on and off should be pretty fast(I think), so you shouldn't have to worry about contexts switches with the lights.

Also, if you have static lights, you might consider using lightmaps. Lightmaps help a lot with scenes that have many lights.

[LastBoyScout]

Hi Fool Running,

thx for your answer, I didn't know that: So the light data is hardwired you can only change the treatment/interpretation of it?

The maximum number of lights activated per node right now is 6. But things are sooo simple (just height map and and a train going roughly in circles on a track, really less triangles!) that even 8 lights shouldn't hurt. And the load is never high (keeping 35fps, most of the 1/35secs the render loop is idling and waiting for the next frame time).
So I don't think those 6 lights are slowing down right know, not yet .

What I tried: Every frame I loop throu 200 "fake lights" and send them to opengl. They aren't used. I am just checking the cost of those state changes. Now when I do that, rendering is not smooth... even stranger: It's not just constantly slow (what I would expect) it is very slow sometimes and then for a short period he can again keep up with 35fps and then back to slow... quite strange considering the most work per frame is in those fake light state changes, which should be constant.

If you say light changes should be pretty fast: Do you consider 200 changes to be many changes? I really don't have any intuition or data about this, I am new to 3D/opengl.

I have 21 lights in my world and looking at the whole world my renderer has to enable and send a complete light about 90 times (so I think there is much to improve with 21 being the lower bound...).

Anyway, can anyone confirm that 90 changes are to much?
My graphics card and cpu are more or less up to date, ati x800 pro and dual core 2.2ghz. (And enough ram, no swapping involved.)

PS: Though not yet used I do know about lightmaps, but thx. In the end I will have a special handling for static lighting of course. But right know I am experimenting with the dynamic part.

PSS: I read about "virtualized lights". It seemed as if they would reset the lights for every object they draw which is even more brutal compared to what I do. But maybe having objects sorted in a spatial order helps there.

thx
LastBoyScout

[darkprophet]

if you are talking about shaders and such, heard about deferred shading?

DP

[LastBoyScout]

Hi all,

ok thx for the posts. The solution is embarrassing simple...
Setting/changing lights is not a problem at all and things are running smoothly now it was just the dam creation of the native buffers.
I did the class Light a long time ago and didn't go into it again, turns out I was creating a new native/direct buffer everytime I send the state...

I am sorry to have bothered any of you, was just stupid.

thx
LastBoyScout