• Advertisement
Sign in to follow this  

Scene Graph?

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

How can you visualize the scene graph? Aside from the wikipedia definition. I know its a tree data but does it reside? Is the scene graph the world?

Share this post


Link to post
Share on other sites
Advertisement

As there are a lot of opinions regarding what the term "scene graph" means, it might be better if you describe what you want to do, what aspect of programming you're curious about.

 

With regard to the wikipedia definition: be an aware consumer - many of the articles comprise the equivalent of advertisements and use the term "scene graph" to describe their products, rather than to indicate that their product implements a "scene graph." If you look at the "scene graph" products listed, you'll find there really isn't a lot of commonality among them - either in structure or function. blink.png

 

 

 


Is the scene graph the world?

 

First: using the term THE scene graph may not be quite correct. As mentioned, it depends on what aspect of programming you're asking about. A scene graph can be used as a hierarchy in the sense that it can be used to maintain parent-child relationships. However, if, by "world," you mean meshes, textures, etc.: no, it's not (or shouldn't be) the world.

 

L. Spiro's discussion provides some clarification on what a "scene graph" can be used for. That article represents a scene graph as:

 

A scene graph is a simple hierarchy of nodes that allow propagating properties from parent nodes down to children nodes.  It is nothing more.

 

 

As mentioned above, rather than using a term that has various meanings, can you describe what data or process you want to discuss? Mesh hierarchies? Frustum culling? Render sorting?

 

EDIT: Apologies if I'm making an incorrect assumption about why you're asking the question. IF you're new to game programming, don't get caught up in "A lot of programs seem to have a scene graph. I'll put one in my program."

Edited by Buckeye

Share this post


Link to post
Share on other sites

As there are a lot of opinions regarding what the term "scene graph" means, it might be better if you describe what you want to do, what aspect of programming you're curious about.

 

With regard to the wikipedia definition: be an aware consumer - many of the articles comprise the equivalent of advertisements and use the term "scene graph" to describe their products, rather than to indicate that their product implements a "scene graph." If you look at the "scene graph" products listed, you'll find there really isn't a lot of commonality among them - either in structure or function. blink.png

 

 

 


Is the scene graph the world?

 

First: using the term THE scene graph may not be quite correct. As mentioned, it depends on what aspect of programming you're asking about. A scene graph can be used as a hierarchy in the sense that it can be used to maintain parent-child relationships. However, if, by "world," you mean meshes, textures, etc.: no, it's not (or shouldn't be) the world.

 

L. Spiro's discussion provides some clarification on what a "scene graph" can be used for. That article represents a scene graph as:

 

A scene graph is a simple hierarchy of nodes that allow propagating properties from parent nodes down to children nodes.  It is nothing more.

 

 

As mentioned above, rather than using a term that has various meanings, can you describe what data or process you want to discuss? Mesh hierarchies? Frustum culling? Render sorting?

 

EDIT: Apologies if I'm making an incorrect assumption about why you're asking the question. IF you're new to game programming, don't get caught up in "A lot of programs seem to have a scene graph. I'll put one in my program."

 

Uhm since im new to game programming Im not really sure how to explain it. But looking at my code. I think its all about drawables and textures and sprites that you will display on the screen. Thats why im having a trouble understading scene graph. Reading it makes me more confuse. So if its not a stage or world then what it is like?

 

Here is part of the book I am currently reading that explains a little about scene graph

 

In order to manage transform hierarchies in a user-friendly way, we develop a scene graph—a tree data structure consisting of multiple nodes, called scene nodes. Each scene node can store an object that is drawn on the screen, most often this is an entity. Each node may have an arbitrary amount of child nodes, which adapt to the transform of their parent node when rendering. Children only store the position, rotation, and scale relative to their parent. A scene graph contains a root scene node, which exists only once in a world. It resides above all other scene nodes in the hierarchy, thus it has no parent node.

 

Reading it again makes me think this has nothing to do with game programming? Its more like a physics term called "space"? Where a node is an object on a space? Is my logic right?

Share this post


Link to post
Share on other sites


Reading it again makes me think this has nothing to do with game programming? Its more like a physics term called "space"? Where a node is an object on a space? Is my logic right?

 

Well, scene graph isn't *limited* to game programming, but almost every single non-trivial game has a scene graph of sorts.  That said, do do all kinds of other programs, such as 3D modellers, CAD/CAM software, etc.

 

Basically if the project has stuff in it, and that stuff has a position, it's got a scene graph.  Arguably you would even call the data structure that holds UI information a scene graph, in that a window can contain a toolbar, which in turn contains buttons, etc.

 

The scene graph is simply the data structure that this information is stored in.  How the information is stored and how nodes within the graph are related is entirely dependent on the game itself.  

 

 

So, in most basic terms, a scene graph is the data structure used to hold stuff that has position in a game or applications "world".  Nothing more.  

Share this post


Link to post
Share on other sites

I think it's first useful to know that you can (and should!) represent your game world in a number of different ways. For example, you might have one way to represent how your game entities are positioned in relation to each other, another way might be a simple array because you only care about their existence, and another way might be grouping them by proximity because you want to work on groups of entities which are close to each other. Different representations are better because you will want to process the entities in your world in different ways efficiently, but unfortunately there is no one-size fits all data structure.

 

A scene graph is one way of representing your world and as you've said it's a tree-like structure which contains all the entities in your world, and each entity might have any number of children which should move with its parent. e.g. for a knight holding a sword, you would have one node for the knight which would have a child node for the sword. Each node has two transformations: a global transformation which is always relative to the world's origin ("world space"), and a local transformation which is always relative to its parent's origin ("model space"). If the knight is a child of the root node, then the knight has a local transformation which is relative to the world's origin, and the sword has a local transformation which is relative to the knight's origin. Every time the knight's global transformation changes, you then propagate its global transformation down to the sword to update the sword's global transformation. The 'shape' of a scene graph naturally lends itself to dealing with these hierarchies easily because you have to access the nodes nearest the root first, before you can access the child nodes.

 

As for what specifically you put a in a scene graph, I would create a "SceneNode" struct/class which contains a global and local transformation, a list of its children, and a pointer back to the thing that the node is a placeholder for (one of your game entities).

Share this post


Link to post
Share on other sites

Reading it again makes me think this has nothing to do with game programming? Its more like a physics term called "space"? Where a node is an object on a space? Is my logic right?

 

I wouldn't say it has nothing to do with game programming. It's a concept whose implementation in various ways is used in game programming, and that may be it's most common usage. A scene graph is often used to determine how an object is transformed** with relationship to its parent, as opposed to a quadtree or octree, which is often used to keep track of where objects are, after they have been transformed.

 

The analogy with a "space" is pretty close. A scene graph could represent the solar system, with planets being children of the sun, satellites being children of the planets, etc. Each child would be influenced by its parent in translation and rotation, which each parent "passes" on to each of its children. Note, however, that the scene graph does not keep track of data, rules or methods for transformations, just relationships among objects.

 

**EDIT: or, rather, what influences an object. I.e., it's parent. More in the direction of "something has changed in the scene. Tell each object to check it's own transformation, and pass any changes to its children, who pass changes on.."

 

EDIT2:

 

 


So if its not a stage or world then what it is like?

 

As a contrived example, consider a cruise ship in the Caribbean. All the passengers and machinery move about with the ship. For this illustration, consider the ship, passengers, crew and machinery to be children of the root node - the Caribbean sea. Assume your graphics application views the ship from outside, and you can look "inside" the ship with x-ray eyes, sort of a Sim-ship. As the ship translates and rotates on the surface of the sea, all the children (passengers, crew, machinery) must translate and rotate with it. Further note that each passenger/crew member can wander about inside the ship, making their own translations and rotations. However, those child translations and rotations will always be with respect to the current position and rotation of the ship.

 

To render a view of just a portion of the ship, two primary steps are taken. First, a scene graph can be used to "tell" the ship that it's changed position. The ship updates its position and rotation, and then passes that information on to all its children. A passenger may be walking along a corridor, oblivious of the ship's change in orientation, but viewed from the "scene," the sea, the corridor itself is translating and rotating. The passenger translates along the corridor, but the passenger's translation with respect to the water is a combination of the ship's movement and the passenger's movement within the ship. Following the ship's update, and all its children updating their orientations with respect to the ship, each object now has a different position and direction with respect to the sea.

 

As mentioned above, you desire to render only a portion of the ship. If you use the scene graph to render the scene, you'll end up drawing a lot of objects that don't appear in the current view. So, separate from the scene graph, you can maintain a quadtree or octree (or similar structure) which stores updated information for where objects are currently. You can then search through the quadtree, looking only at the areas of the ship which will appear in your view, and add objects to a render queue.

 

So the scene graph, as your book mentions, has a root node - the sea itself. One of its children is the cruise ship - a child node of the root node. The node may have information relating to the object - it's a ship, it's a cruise ship, and perhaps it's #3 in the list of ships you're maintaining. Logic or code apart from the scene graph is called to update the ship's course, its position and heading. That orientation data is passed on to the ship node's child nodes. One of those nodes is of type "person" - perhaps person #456 in the "people" array. Logic and code is executed to determine if person #456 should update it's location and orientation with respect to the ship. Then the world position and orientation of that person is determined. Another node may be of type "engine." The engine rotates at some RPM, and passes its current rotation on to a child node of type "propeller shaft." Etc.

 

The above situation is contrived, obviously, but hopefully gives you an idea how a scene graph can be used to determine what objects require data from other parent objects for updating. The engine will translate and rotate with the ship, but will also rotate locally itself. The attached propeller shaft rotates and translates with the ship, but must have the current rotation information from the engine. A node doesn't have to "know" whether it's parent is the ship, or an engine, or a propeller shaft. It just needs to know that it's parent is now at so-and-so position, with such-and-such heading.

 

It's a tool (not a requirement) that can be used to ensure that objects are all updated, and updated with the data they need to do that.

Edited by Buckeye

Share this post


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

  • Advertisement