• Create Account

## Scene Graphs and Lights

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

8 replies to this topic

### #1_diego  Members

184
Like
0Likes
Like

Posted 04 December 2013 - 12:26 PM

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...

### #2haegarr  Members

7186
Like
3Likes
Like

Posted 04 December 2013 - 01:20 PM

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.

### #3_diego  Members

184
Like
0Likes
Like

Posted 04 December 2013 - 03:42 PM

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?

### #4Hodgman  Moderators

49387
Like
4Likes
Like

Posted 04 December 2013 - 04:41 PM

A transformation hierarchy and a culling system are two very different problems, which both have very different optimal data representations.
It used to be very common to try an solve every problem using a single graph data structure, but it's a very flawed approach and is not popular any more.

http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D

### #5Vilem Otte  GDNet+

2660
Like
2Likes
Like

Posted 04 December 2013 - 05:53 PM

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.

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

### #6Samith  Members

2450
Like
0Likes
Like

Posted 04 December 2013 - 06:13 PM

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.

### #7L. Spiro  Members

24826
Like
4Likes
Like

Posted 05 December 2013 - 02:36 AM

I made this just for you: Scene Graphs

L. Spiro

### #8McGrane  GDNet+

1657
Like
0Likes
Like

Posted 05 December 2013 - 11:00 AM

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

### #9_diego  Members

184
Like
0Likes
Like

Posted 06 December 2013 - 04:52 AM

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.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.