SceneGraph understanding

So far i can understand that it is a tree data structure consisting of multiple nodes.

If i draw an entity in world without any scenegraph, e.g. I have an object "Aircraft" which inherit from object "Entity"... so far so good i guess.

But what if i use scenegraph? if i draw an entity in world with scenegraph, i still have an object "Aircraft" which inherit from object "Entity" but now my object Entity inherit from a object "Node"? what is the diference? i still move my aircraft as the same without a scenegraph? or do i need to move node instead of aircraft?

You're confusing Entity Heirarchy with Scene Heirarchy from what I can tell.

It Works something like like this:

class Scene
{
Collection<Entity> Objects;
}

class Entity {
Collection<Entity> Objects;
}

class Bullet : Entity { }

class Aircraft : Entity {
void Shoot() {
}
}


then in game code ....

CurrentScene = new Scene();



Not the best example I admit, but I think it covers the idea based on your explanation of the problem.

I took this a step further when Iwas building engine code and had something like:

interface IEntityContainer
{
Collection<Entity>
}

class Scene : IEntityContainer { ... }
class Entity : IEntityContainer { ... }

• Thank you for your answer and your time. If i understood, Scene Object as access to all Collection Objects, and from there we can look for Aircraft inside Collection and call Shoot fucntion. – Nuno Barão Feb 24 '15 at 19:39
• Yeh some actually define a SceneNode object and think of the full tree as just nodes that may or may not contain other Entities but I find this the simplest way ... Unity3D shows this off quite well if you need a simple example of scene structure. – War Feb 24 '15 at 19:49
• I guess your explanation worked well, but it seems i still have a doubt. What is the difference it makes to have the nodes? I mean ... what's the point? It would not be the same have all the objects in a vector or array? Thank you very much – Nuno Barão Feb 24 '15 at 20:45
• The idea behind the scene graph is to determine the relationships between objects in the scene, but also the impact if one should be updated. For example: If I have a person in my scene wearing a hat, when my persons head moves so should the hat, making the hat a child of the head and the head a child of the person in this fashion means that moving the person moves all 3, and things like physics can be applied to the whole tree or portions in the same way. It's a commonly accepted pattern for looking after a large set of objects, no rules say you have to do things this way though. – War Feb 24 '15 at 20:55
• That makes sense. I am new here and can´t put a +1, but your answer and comments clarified me! Thank you very much. – Nuno Barão Feb 24 '15 at 21:10

To elaborate on what Wardy said, there are some really important object attributes that are integrally related to this tree structure and could not be expressed as easily if the objects were merely stored as a "scene list". For example, take position and scale. Normally moving an object will also move the children. This is because each object stores its scale as an offset from a parent. It's very convenient, and it would not be as straightforward if objects were stored in a different way. Scale is similar--if an object is marked as scale=50%, all its children will be also.

The king of attributes is whether an object is active--should it be updated? Should it be rendered? So if you set a character inactive, his skeleton, his guns, his hair, etc., will all become inactive. (This isn't true for all game engines.) But an intelligent game engine can assume that if an object (the character) is disabled, the child objects underneath have no need of continuing logic. The hair doesn't need to blow in the breeze. And because of this tree structure, you don't need to update the attributes of all the children. The way Unity expresses this is having two ways to look at object activity: "activeSelf", and "activeInHierarchy". The former is the "active" bit, and the latter is whether it's really active (based on its own state, and the state of its parent object).

(I meant to post this as a comment, but I accidentally typed too much because the text box didn't tell me to stop! Well, I was typing in the wrong text box. ;-) )

• Yeh scene graphs are really about managing stacks of Transforms with relationships (parent, child). Getting the structure in place is the key to getting started, worrying about that can come later. I think the OP was really just asking about structuring his entities within the scene at this point though so I didn't want to add too much complexity around "this matrix is the result of a stack of matrix math from the scene up the tree to this point". – War Feb 25 '15 at 13:10
• I am grateful for your answers, thank you for your time and help. – Nuno Barão Feb 25 '15 at 14:40
• @Wardy, I meant that the relationships are logically hierarchical, not just mathematical. UI frameworks may use these same principles, despite not being able to take advantage of combined math operations. If a UI object is fading out and has 50% alpha, it's likely you would want its children (and their children) to implicitly share that trait. And at least for the UI toolkits implemented within a game engine, that's not a math optimization--just good organization. And Nuno, glad to help! – piojo Feb 26 '15 at 3:46
• Yeh what I was saying ...just not very well lol. – War Feb 26 '15 at 13:48