• Advertisement
Sign in to follow this  

Light Management in Scene

This topic is 4322 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What are some good ways to manage lights in a scene? My "world" is composed of a set of geometry "chunks", and a series of lights. There may be any number of both. The 3D hardware can only handle a certain number of active lights at a given time, so I need a way to determine when to enable/disable each light so that image quality and speed are maximized. I've come up with two ideas: 1) For a given scene at a given camera position, the amount of visible geometry lit by each light is calculated. The lights that affect the most visible geometry are enabled. All lights beyond the hardware-defined limit will not be used. Whenever the camera or a significant amount of geometry moves, these calculations will be repeated. 2) Each chunk of geometry maintains a list of all lights that affect it. When the renderer iterates through the list of chunks, each light in the world is enabled or disabled depending on the current chunk's light list. Each chunk's list of lights would need to be updated whenever the chunk or any light in the world moves. I'm leaning towards option #2, but I'm worried that the large number of light setup/enable/disable calls may be a performance problem. Option #1 would probably be faster, but coming up with a good algorithm could be tricky. Also, the scene quality wouldn't be as nice, since only a small number of lights would be used to light the entire visible world. Thoughts?

Share this post


Link to post
Share on other sites
Advertisement
3) Each Light maintain a list of Meshs/Objects it affects (quick BoundingVolume test), updated whenever something moves in/out-side of the Light's Area of Effect [BoundingVolume]
Keep the n most important lights (those which projected bounding volume area are the biggest), skip the others.

That will become especially useful when you use shadowing techniques, be it Shadow Volumes (very fillrate & vertex intensive) or Shadow Maps; in both cases you don't want more than a maximum light count or the performances will suffer tremendously.

Share this post


Link to post
Share on other sites
So it wouldn't be a good idea to constantly enable/disable lights as a scene is rendered? It is better to simply calculate the n best lights and use them for an entire scene?

Share this post


Link to post
Share on other sites
Quote:
Original post by doctorsixstring
So it wouldn't be a good idea to constantly enable/disable lights as a scene is rendered? It is better to simply calculate the n best lights and use them for an entire scene?


Well it's not about that at all, obviously you will enable/disable lights anyway.
The thing is in the case of a ShadowMap design, you'll only have n ShadowMaps (restrained resource), so you won't be able to have more than n Lights enabled in any given frame (n can be whatever you want [no relation with OpenGL light limit]).
Also you will process each Light one at a time, instead of 1-8 Lights like in "deprecated" OpenGL lighting system.

Share this post


Link to post
Share on other sites
I don't understand why using a shadow map (or not) would affect how I determine when to enable/disable lights.

Basically, I want to know if it is better to render all visible geometry with a single set of lights, or with a large number of lights that are enabled/disabled depending on which chunk of geometry that is currently being rendered.

It seems like you are suggesting that I first determine which lights are the most important, then render all my geometry from the viewpoint of those lights. This seems like it would be a substantial performance hit, since I would be rendering a lot of geometry multiple times (once for each light). It would also play havoc with trying to sort all geometry in the scene by transparency, depth, material, texture, etc.

Share this post


Link to post
Share on other sites
Perhaps it would be best to meet somewhere in the middle. You wouldn't want to generate shadow maps for every little light in a room, but just for the one or two main lights of a scene. So you would probably want to identify the most important lights in the scene for shadow map generation. Then, for individual batches of geometry, I would probably go with whatever lights where most important to that batch. That way, if you had a scene of, say, a room with a grand chandelier and a bunch of small candles along the walls, The chandelier could be the only shadow caster, while the candles contribute light to the scene properly.

Share this post


Link to post
Share on other sites
Quote:
Original post by doctorsixstring
Basically, I want to know if it is better to render all visible geometry with a single set of lights, or with a large number of lights that are enabled/disabled depending on which chunk of geometry that is currently being rendered.

You may change the lightset for each Mesh it shouldn't hurt performance.


I'm sorry I wasn't clear, but I assumed you would go shadowmaps/volumes, in which case the processing of your scene is different.
See that article to have an idea.
(Basically you process the geometry within the light Area of Effect once per light, in order to get proper lite areas, it's not that different with shadowmaps since you need bind the correct shadowmap)

Share this post


Link to post
Share on other sites
I may want to add support for more advanced techniques in the future, but for now, I just want to get a basic lighting system going.

Thanks for the info, though. I'll take a look at that article.

Share this post


Link to post
Share on other sites
I like the idea of being able to attach lights to nodes in the scene graph and then having them effect that node and all its children. David Elberly does something similar in Wild Magic 3.

Share this post


Link to post
Share on other sites
The idea is to choose lights based on the following rules:
- first we check distance: every light in a specific radius is considered a light source
- if the light source is in this radius, we check if its attenuation is high enough to exclude it from the list
- if the light source is in a specific radius and not attenuated enough to be ignored, we compare its distance to the distance of all other considered light sources and prioritize it based on distance
- then we check if it has a dominating color. If it is only white or greyish it does not have as much influence on the scene, as if it is colored ... so the later lights might get a higher priority
- then we check if it has a higher chromacity than the other lights that are considered as a light source

then we will have a list of lights with different priorities ... the first four - eight will be shown on the object ...

then there are shadows. We can assume that four shadow maps are pretty much ... right? ... so maybe you want those to end up always based on the priorities above at four lights that case shadows ... obviously shadows need to follow the light color here ...

... this is just a list of things you might consider if you think about a light manager. Maybe your priorities are different or you can exclude a few of the points of the list because your game do not need it.

Share this post


Link to post
Share on other sites
Quote:
Original post by noNchaoTic
I like the idea of being able to attach lights to nodes in the scene graph and then having them effect that node and all its children. David Elberly does something similar in Wild Magic 3.


Having the lights being groups that lit their children is not the way to go for advanced light management system. It will only fits for very simple scene. For example ; how do you model the lights of a car, a torch being carried by a moving character, an explosion which spawns point lights moving away,...

In my engine, I maintain a list of the influencing lights on a per node basis. Each node has a node interpreter associated with it at runtime, it's the task of he node interpreter to interpret the context (influencing light list, influencing environment nodes like fog and such, transform...) to shade the node.

The renderer performs usual culling to know the lights which influences the render frame. The lights influencing the render frame updates the context of the node they influence using an adapted culling technique.

The way the light list is processed depends on the node interpreters ;
- the fixed function pipeline interpreter use up to the 8 most influencing lights (note that I never encountered a scene which really needed more than 8 lights ; the sorting key if there are more than 8 lights for a given node is the attenuation at the center of the bounding sphere of the node).
- the shader system just generate a shader for the amount of influencing lights (splitting pass if needed).

There is an interesting paper at Terathon software about light culling techniques.

Hope it helps

Vincent

PS : After re-reading the original post, I think the expected answer is a bit more simple ; as Ingenu said, you can switch the light set, it should not kill performance.

Share this post


Link to post
Share on other sites
Quote:
There is an interesting paper at Terathon software about light culling techniques.

Yep I forgot that one. Before you look at the light sources you have to find out first, which light is really visible to the object in question ... the light might be behind a wall ...

Quote:
In my engine, I maintain a list of the influencing lights on a per node basis. Each node has a node interpreter associated with it at runtime, it's the task of he node interpreter to interpret the context (influencing light list, influencing environment nodes like fog and such, transform...) to shade the node.

The renderer performs usual culling to know the lights which influences the render frame. The lights influencing the render frame updates the context of the node they influence using an adapted culling technique.

Your engine is very cool :-)

Share this post


Link to post
Share on other sites
only limiting the number of lights on an object to X value
whilst sounds good in theory. doesnt actually work in practice without having visual mistakes (from memory years ago i used to cap the number of lights per obj at 12 but even with such a high number there were occasional visual errors during a time of great light activity)
u engine should be able to handle >20 lights per object.
though i think i do it the other way around the lights store the objects, iethe objects know nothing about whatever lights are nearby (then again i am doing shadowing as well, off the top of my head if u dont do shadowing u might wanna store things the other way, ie the meshs know about the lights

Share this post


Link to post
Share on other sites
Quote:
u engine should be able to handle >20 lights per object.
That's a lot. Then I would say it depends on the hardware platform you are running on. Assuming next-gen consoles I would find that high :-)

Share this post


Link to post
Share on other sites
true, it is a lot but situations can happen like that in my game (lots of explosions, lazers etc in a confined space) though since ive added shadowing for all lights (crap quality but fast) ive had to reduce the possibilty of large number of lights occuring,
eg (pre shadowmaps) explosion with 10 light casting bits of debris
but (nowadays) just one bigger light in the center

Quote:
Then I would say it depends on the hardware platform you are running on

btw i wrote the the original light routine on a gf2mx + celeron433 (which does have benifits when u run on todays hardware :) )

[Edited by - zedzeek on April 26, 2006 10:12:55 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Niwak
Quote:
Original post by noNchaoTic
I like the idea of being able to attach lights to nodes in the scene graph and then having them effect that node and all its children. David Elberly does something similar in Wild Magic 3.


Having the lights being groups that lit their children is not the way to go for advanced light management system. It will only fits for very simple scene. For example ; how do you model the lights of a car, a torch being carried by a moving character, an explosion which spawns point lights moving away,...

In my engine, I maintain a list of the influencing lights on a per node basis. Each node has a node interpreter associated with it at runtime, it's the task of he node interpreter to interpret the context (influencing light list, influencing environment nodes like fog and such, transform...) to shade the node.

The renderer performs usual culling to know the lights which influences the render frame. The lights influencing the render frame updates the context of the node they influence using an adapted culling technique.

The way the light list is processed depends on the node interpreters ;
- the fixed function pipeline interpreter use up to the 8 most influencing lights (note that I never encountered a scene which really needed more than 8 lights ; the sorting key if there are more than 8 lights for a given node is the attenuation at the center of the bounding sphere of the node).
- the shader system just generate a shader for the amount of influencing lights (splitting pass if needed).

There is an interesting paper at Terathon software about light culling techniques.

Hope it helps

Vincent

PS : After re-reading the original post, I think the expected answer is a bit more simple ; as Ingenu said, you can switch the light set, it should not kill performance.


Thanks for that, just downloaded the Terrathon slides. :-)
Rating++

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement