Jump to content
  • Advertisement
Sign in to follow this  
kosmon_x

Question about scene graph object access

This topic is 4869 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

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 :)

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
shameless bump

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.)

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!