I'd like to have a feature in the default SceneManager for linking lights directly to renderables/scene nodes.
Currently, correct me if I'm wrong, the default scene managed uses the light radius to determine which objects should be rendered with a light.
I'd be amazing if there was an alternative way of doing things such that you can turn off this functionality and connect objects to lights by manually adding the lights to the object. Does this functionalit already exist?
Of course, a custom scene manager could implement this easily. However, I think this functionality would be useful for many/most real scene managers, so putting it into the default scene manager would be amazing.
There are simple reasons why you might want to do this, mostly to do with realtime lighting in an indoor setting. Lights are often close to walls, and objects on the other side of a wall should not be affected by a light just because it is nearby. I know, I know, again this sounds like custom scene manager stuff. However, if the functionality was in the default scene manager I could create my editor to rely on this fact and be able to work with any scene manager. My editor will be used for both indoor and outdoor scenes, and while outdoor it often doesn't matter, indoor is a different story. I'd like to hook up objects to lights on a room by room basis by manually adding lights to objects in that case.
Thoughts?
Clay
Linking lights directly to renderables
- Falagard
- OGRE Retired Moderator
- Posts: 2060
- Joined: Thu Feb 26, 2004 12:11 am
- Location: Toronto, Canada
- x 3
- Contact:
-
- OGRE Retired Team Member
- Posts: 1603
- Joined: Wed Oct 20, 2004 7:54 am
- Location: Beijing, China
- x 1
Yes, user configurable light finding already in my mind, we are talked somewhere else. This is the origin idea:
Anyway, suggestions are welcome .
We need some time to designing and coding, and might go to Dagon or later.User configurable light finding algorithm. Suggest: movable object has a light query flags, this query flags similar scene query flags but was used to light query. Shadow generate should use same light finding algorithm, which a bit hard to achieve.
Anyway, suggestions are welcome .
- Falagard
- OGRE Retired Moderator
- Posts: 2060
- Joined: Thu Feb 26, 2004 12:11 am
- Location: Toronto, Canada
- x 3
- Contact:
Ah yes, I like the idea of an object query. It lets me perform custom logic for knowing what lights hook up to what objects.
How often to perform the queries might become a problem though.
It may be better to start with a system where each object can have a list of lights that effect it, and a flag to say not to automatically add lights based on distance if that's what the programmer wants, and then build a query system on top of that to populate the lights for each object based on the query. This might allow you to implement the light list idea quickly and in an earlier version of Ogre, and then add the query functionality later.
For the querying, it'd be awesome if Ogre still did the distance check for lights and then asked the object whether the light should be added to it. I assume that's what you mean by querying, but it'd be nice if the system did it by default based on radius so the programmer wouldn't have to do all the work of forcing objects to be "dirty" and require a re-query.
Basically, the optimal solution in my mind would be if an object moves you flag it as requring a re-query which means a query will happen on it for each nearby light, and the same for when a light moves, it flags nearby objects and requeries.
How often to perform the queries might become a problem though.
It may be better to start with a system where each object can have a list of lights that effect it, and a flag to say not to automatically add lights based on distance if that's what the programmer wants, and then build a query system on top of that to populate the lights for each object based on the query. This might allow you to implement the light list idea quickly and in an earlier version of Ogre, and then add the query functionality later.
For the querying, it'd be awesome if Ogre still did the distance check for lights and then asked the object whether the light should be added to it. I assume that's what you mean by querying, but it'd be nice if the system did it by default based on radius so the programmer wouldn't have to do all the work of forcing objects to be "dirty" and require a re-query.
Basically, the optimal solution in my mind would be if an object moves you flag it as requring a re-query which means a query will happen on it for each nearby light, and the same for when a light moves, it flags nearby objects and requeries.
-
- OGRE Retired Team Member
- Posts: 1603
- Joined: Wed Oct 20, 2004 7:54 am
- Location: Beijing, China
- x 1
Yes, distance-based light finding still and always available, the query flags is an additional condition allow kick out needless lights.
But I don't think the light list need to cache up, find lights by base on distance is fast enough. Cache light list for each movables have memory overhead problem, and maintenance reference between light and movable and need to notify each other when the properties changed, this would be harm performance.
Allow callback mechanism to populate light list almost good ideas, but it's hard to support shadow generate, especially for texture shadow, and seems no advantage in performance. But once we can find out good method to support it, we will.
But I don't think the light list need to cache up, find lights by base on distance is fast enough. Cache light list for each movables have memory overhead problem, and maintenance reference between light and movable and need to notify each other when the properties changed, this would be harm performance.
Allow callback mechanism to populate light list almost good ideas, but it's hard to support shadow generate, especially for texture shadow, and seems no advantage in performance. But once we can find out good method to support it, we will.
- Falagard
- OGRE Retired Moderator
- Posts: 2060
- Joined: Thu Feb 26, 2004 12:11 am
- Location: Toronto, Canada
- x 3
- Contact:
I think the memory overhead would be negligible in the grand scheme of things, compared to say... a single mesh in memory.
Better to eat up a few thousand bytes of memory than to query every object every frame in my opinion. I could be wrong here considering it already does something like this based on distance right now doesn't it? That seems a bit wasteful - in a big scene with lots of objects does each light check every object in the scene to see if it's within the minimum distance?
Also, this would be optional.
Clay
Better to eat up a few thousand bytes of memory than to query every object every frame in my opinion. I could be wrong here considering it already does something like this based on distance right now doesn't it? That seems a bit wasteful - in a big scene with lots of objects does each light check every object in the scene to see if it's within the minimum distance?
Also, this would be optional.
Clay
-
- Hobgoblin
- Posts: 559
- Joined: Wed Oct 19, 2005 4:57 pm
- Location: LS87, Buenos Aires, República Argentina.
One nice thing would be to have "special effects lights". That is, custom lights for a specific moveable. Those lights, in the form of a light list, would only apply to that object. It's very common to need that kind of stuff, IMO: gunshots in a spaceship (where rarely they light up other objects - may as well make them local and forget about other objects for performance's sake), cockpit lights (in flight/space sims), that kind of stuff.
It would be easily implementable, IMO.
It would be easily implementable, IMO.