Question about scene graph object access
Author
Hey, so I understand the basic concept of a scene graph, however I'm a little shaky on how exactly everything is stored. Do the scene graph nodes own all of the objects, or do you have a list of objects somewhere else, and each node simply points to a few of them (whichever ones are in the particular node). If this is the case, how do people usually give the nodes access to the objects?
I'm specifically interested in how the camera is handled. I want my camera to belong to one of the nodes, but I also want to have easy access to it outside of the graph no matter what node it's currently in (to grab the view matrix from it, etc). Yet, I still want it to be able to move smoothly throughout the scene graph depending on its position. How does everyone implement this?
Something else -- I want my scene graph to be able to alter the positions of my objects whenever they change nodes (including the camera)...
Thanks :)
Most scene-graph nodes don't store much, they mostly reference other data which is often stored as a list in some kind of manager structure.
For example: a mesh node in a scene-graph doesn't store the mesh data itself, it references a mesh object and renders it when necessary. The mesh node can access the data by using public methods of the mesh class.
As for altering positions, it is a good idea to create a translation node which stores a matrix, when updating & rendering the scene-graph the node would transform all its children, there may even be more translation nodes below it too.
I suggest you look at the composite pattern for a scene-graph structre and gander at the visitor pattern & double dispatch for traversals.
One commonly overlooked idea is multiple cameras but this is often overcome by using multiple scene-graphs too. So its up to you. You could create a camera node that is treated much like any other - you can access the camera by maintaining a reference or pointer to it elsewhere. I prefere the idea of making a scene-manager class which stores the camera itself so you can access the camera using a method of the scene-manager (which would also be the root of the scene-graph).
Some scene-graphs use the camera to issue traversals for rendering etc but I don't like too much, I prefere to issue the traversal from the scene-manager. But its simply a preference I can't see any advantage either way :)
good luck
For example: a mesh node in a scene-graph doesn't store the mesh data itself, it references a mesh object and renders it when necessary. The mesh node can access the data by using public methods of the mesh class.
As for altering positions, it is a good idea to create a translation node which stores a matrix, when updating & rendering the scene-graph the node would transform all its children, there may even be more translation nodes below it too.
I suggest you look at the composite pattern for a scene-graph structre and gander at the visitor pattern & double dispatch for traversals.
One commonly overlooked idea is multiple cameras but this is often overcome by using multiple scene-graphs too. So its up to you. You could create a camera node that is treated much like any other - you can access the camera by maintaining a reference or pointer to it elsewhere. I prefere the idea of making a scene-manager class which stores the camera itself so you can access the camera using a method of the scene-manager (which would also be the root of the scene-graph).
Some scene-graphs use the camera to issue traversals for rendering etc but I don't like too much, I prefere to issue the traversal from the scene-manager. But its simply a preference I can't see any advantage either way :)
good luck
The concept of a 'scene graph' is nebulous, at best. Exactly what constitutes a scene graph, what it should store, etc. is entirely up to the person who is writing it. Some scene graphs strive to be complete solutions for managing everything in the system. Others serve as little more than transformation hierarchies.
Probably the easiest way to deal with the problems you mention is by having the scene graph store references (pointers) to the objects in question. So you have a list of cameras somewhere. These cameras have also been attached to scene graph nodes, and their transformation information (if you choose to have any) is relative to the parent node. But when you're activating a camera, you pull it out of the list of cameras and use a parent pointer stored in it to access the relevant part of the scene graph, and follow that upwards to complete your transformation. (For performance, it might be a better idea to resolve the transformations through the entire scene graph first and cache the final transformations in nodes.)
Probably the easiest way to deal with the problems you mention is by having the scene graph store references (pointers) to the objects in question. So you have a list of cameras somewhere. These cameras have also been attached to scene graph nodes, and their transformation information (if you choose to have any) is relative to the parent node. But when you're activating a camera, you pull it out of the list of cameras and use a parent pointer stored in it to access the relevant part of the scene graph, and follow that upwards to complete your transformation. (For performance, it might be a better idea to resolve the transformations through the entire scene graph first and cache the final transformations in nodes.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
