Hi all!

I'm currently working on implementing my own, small game engine. My first question is: what are the best ways to include lights in the scene graph?

I could add a light to a scene node and that light would be applied to all sub-nodes. However, this would not work in the case where a character is holding a torch: the light is attached to the torch, which is attached to the player. This way, the player (and the nearby scene) would not be lit.

Another option would be to keep the lights on a list and apply the N nearest lights to a mesh. However, this does not seem very efficient as, every frame, the distances between lights and nodes would have to be calculated.

This has bugging me out for a while now...

Thank you in advance

It is commonly accepted that the single hierarchy of a scene graph is not suited to model all the different groupings, assignments, orderings, … that are needed. While carrying the torch is a kind of parenting, the lighting is a kind of volume affiliation. These are totally different things.

A solution to this problem is to use structures as needed: In this case install a spatial structure to quickly find neighbored entities, e.g. an octree. Attach the torch by parenting to a skeleton (or simple anchor). Use the resolved position of the torch to query the spatial structure for nearby entities. Then don't use the N nearest lights but the N lights with most effect on the entity due to brightness and distance.

So, should I use both a scene graph and a spatial structure? Should the scene graph chain spatial transformations while the spatial structure should provide spatial queries and culling?

I think I'm confusing things a bit, but I thought they would serve (almost) the same purpose. Is there some article on this matter?

I second what Hodgman said.

I'll also add, that we have a BVH (Bounding Volume Hierarchy) for lights. Their bounding volumes represent area that light affects (e.g. for point light we have a sphere, for spot light it is a cone, and similarly for area lights (as we do support them in our tech)).

Now, first we can quickly tell whether we have to compute with given light (e.g. whether it affects any pixel in given view frustum), second we can quickly tell which lights affect each given object.

The objects we need to test are taken from another BVH, that contains scene objects (we actually split objects in static and dynamic ones - because for static objects you don't need to rebuild the hierarchy, for dynamics you need to either rebuild, or sometimes just refit).

So basically we're working with multiple "scene graphs" in our tech (BVH is actually an implementation that can be used as scene graph). To explain a little bit about BVH (unless you know what it's all about) - check http://en.wikipedia.org/wiki/Bounding_volume_hierarchy

Technically you could also use some spatial hierarchy for this - KD-trees or Octrees for example.

Just like to add a +1 here as your solution sounds almost identical to what we do at my company, though we use an oct-tree instead of a BVH.

Cant ask for much more then for someone to write you an article for an answer :)

Good job, i know it cleared things up for me anyway! - Thanks

Thank you very much for all the answers. Thank you L.Spiro for the article. I'll be reading your posts ;)

I have definitely been reading some outdated stuff. I'll dig into this now.