scenegraph vs components

[font="arial, verdana, tahoma, sans-serif"]This should probably be moved in SW Engineering, it's definetly not a game design thread.
Saying that "scenegraphs are outdated and shouldn't be used any more" really means nothing at all. Perhaps some scene graph management techniques are outdated and should not be used, but I see no way to manage your scene without a graph/tree/structure of some sort. I'd like to read the web pages you have found.[/font]
If I write "component based model" in google I find a lot of links regarding an iterative SW development process. It does not seem what you're meaning here. Perhaps you're referring to composition-vs-inheritance?

1. classic scenegraph (I don't see any advantages in that)

You don't see any advantage compared to what? According to what metric?

3. stay with distributed datastructures (implementation is easy, access is no problem since i've got a central Manager-class, but is it still working when project get's bigger?)

What do you mean for distributed data structures? Since you write that "implementation is easy", I'm fairly sure you're not referring to the distributed data structures I'm thinking about!

Hello everybody,

I am currently writing my first "real" Game-Engine with C++, OpenGL and SDL. The problem is: how to manage objects?
At the moment I'm doing some kind of mix. I would say a "distributed scenegraph" - i got multiple data structures managing the objects:

For example: Updateable.hpp contains a vector, there will probably be a "Moveable" class containing all dynamic objects...

In the internet I found that scenegraphs are outdated and shouldn't be used any more.
While searching for a solution I found the "component based" model, but I do not really understand it
and don't know how to implement such a model in C++. (how should a class get elements of another without inheritance?)

I need an advice and if someone could give me a hint how to implement components, I'd be thankful

So the possibilities are:
1. classic scenegraph (I don't see any advantages in that)
2. component model (sound's nice, but no idea)
3. stay with distributed datastructures (implementation is easy, access is no problem since i've got a central Manager-class, but is it still working when project get's bigger?)
4. other suggestions?

Thanks for replies!

If you have something that works, stick with it. You'll find that engine building is much like working on a car, there is always something that could be better, but you won't know until your there.

I assume that the component model you speak of is an entity component system, If so, there is a good article by purple pwny games( you'll find it as it's on the front page of google when searching for entity systems). Essentially your entity is a container of components, and you create systems to handle those components only. You might have a spatial partition, like an octree or quadtree, that would handle spatial components such as aabbs or obbs. You might also have a physics system that deals with physics components that contain velocity, angular velocity, mass, and moment of inertia. The idea is that these systems should be as independent as possible and only work on the data they need.

Say your player tries to move forward. Your input system recieves a key, and translates that to an action to send to the entity. the entity asks the spatial graph if it's possible. if so it updates it's spatial component. When you render, your render system could query the entity for it's spatial component, and use that to ask the spatial system for a list of objects within the view frustum. each object in this list can then be queried to get the entity it belongs to, and query the entity itself for it's renderable component. these components are then passed to the graphics device to be drawn. It's a round about way of doing something that could be hard coded much more efficiently, but the flexibility offered is a big plus, especially for larger projects.

[font="arial, verdana, tahoma, sans-serif"]Saying that "scenegraphs are outdated and shouldn't be used any more" really means nothing at all. Perhaps some scene graph management techniques are outdated and should not be used, but I see no way to manage your scene without a graph/tree/structure of some sort. I'd like to read the web pages you have found.[/font]

A traditional "scene graph" is a structure that stores rendering states in the nodes of a DAG, and geometry in the leaves. An important (and defining) feature is that node-states propagate to all child leaves.
E.g. a transformation in a node will be concatenated to all children, or a texture binding in a node will be applied to all children, etc...

These particular "scene graphs" are outdated junk for modern games. There used to be a lot of them, and now they're not very popular (because they're evil). Here's a not too old rant about them.

Because "scene graph" has become associated with this particular meaning, it's a good idea not to call your scene management structure a "scene graph" if it doesn't fit that description of storing render-states in the nodes of a DAG which propagate to child geometry.
Call it the transformation graph, or the visibility graph, etc, instead. Usually a modern scene will be represented via several specialized graphs (or flat lists!), not one of these traditional uber "scene graphs".
...Which might be what the OP means by "distributed datastructures"?

and don't know how to implement such a model in C++. (how should a class get elements of another without inheritance?)

Inheritance should be used very rarely! The default way of gaining the behaviors of another class should be via composition, not inheritance.

With inheritance you have:
[font="Courier New"]class Foo : public Bar {}[/font]
With composition you have:
[font="Courier New"]class Foo { Bar bar; }[/font]

Component-based entity systems are just fancy ways of using composition.

Sry for wrong thread-posting...

Thanks to all for the fast replies

@Krohm: i read (didn't try myself) that you can get trouble with a scenegraph because of multiple inheritance. There shall also be situations that can not be handled properly by a scenegraph (not experienced by myself, but this is why I am asking in this forum). ;-)

Hodgman is right: i'm having several specialized graphs, but all are made up with inheritance (till now).
Now I understood the composition principle and I think it's a good addition to my concept.


Is there a way to model a updateable-composition? I'm trying to imagine how my concept would be realized with components/composition.

At the moment I'm having an base class (updateable) and all objects that want to be updated inherit from it.
I'm storing all objects in a vector (in the base class) and just iterator over this vector calling the update-function of the derived classes.

With a composition the objects can not override the update-function, can they? So how do they call different update-functionalities?

Is there a way to model a updateable-composition? I'm trying to imagine how my concept would be realized with components/composition.
At the moment I'm having an base class (updateable) and all objects that want to be updated inherit from it.
I'm storing all objects in a vector (in the base class) and just iterator over this vector calling the update-function of the derived classes.
With a composition the objects can not override the update-function, can they? So how do they call different update-functionalities?

Well, when implementing an interface (e.g. [font="Courier New"]IUpdatable[/font]), is one time where using inheritance is the right thing to do, so it's ok to keep it like that.

For interest's sake though, let's say you've got some inheritance-based code like this:class Animation : public IUpdatable { void Update() { DoAnimation(); } void DoAnimation(); };
class Monster : public IUpdatable { void Update() { DoAI(); } void DoAI(); };

std::vector<IUpdatable*> updatables;
for(...)
updatables->Update();
You could re-write this without inheritance like this:class Animation : { void DoAnimation(); };
class Monster : { void DoAI(); };

std::vector<Animation> animations;
std::vector<Monster> monsters;
for(...)
animations.DoAnimation();
for(...)
monsters.DoAI();

Doing things this second way is closer to "component" style architectures, where objects are mostly made up of links to simpler objects.
e.g. a player might have an animation, a model and a weapon, but doesn't need an Update function of it's own. Each of it's components can update itself. (N.B. this isn't real code -- just trying to get some ideas across)std::vector<Animation*> animationManager;
std::vector<Weapon*> weaponManager;
std::vector<Model*> modelManager;
std::vector<Player*> playerManager;

class Player
{
public:
Player()
{
m_bodyModel = modelManager.size();
modelManager.push_back( new Model("player_body") );

m_animation = animationManager.size();
animationManager.push_back( new Animation("player_anims", m_bodyModel) );

m_currentWeapon = weaponManager.size();
weaponManager.push_back( new Shotgun() );
}
Animation& GetAnimation() { return *animationManager[m_animation] };
Weapon& GetWeapon() { return *weaponManager[m_currentWeapon] };
Model& GetBody() { return *modelManager[m_bodyModel] };
private:
int m_animation;
int m_currentWeapon;
int m_bodyModel;

};

Wow, thanks, really huge effort in your answers.

I think in this special case inheritance is better... You are just having one loop with one vector instead of many.
Nice, so my engine nearly can stay as it is, I just have to keep composition in the back of my mind when going on.

A traditional "scene graph" is a structure that stores rendering states in the nodes of a DAG, and geometry in the leaves. An important (and defining) feature is that node-states propagate to all child leaves.
E.g. a transformation in a node will be concatenated to all children, or a texture binding in a node will be applied to all children, etc...

These particular "scene graphs" are outdated junk for modern games. There used to be a lot of them, and now they're not very popular (because they're evil). Here's a not too old rant about them.

Because "scene graph" has become associated with this particular meaning, it's a good idea not to call your scene management structure a "scene graph" if it doesn't fit that description of storing render-states in the nodes of a DAG which propagate to child geometry.
Call it the transformation graph, or the visibility graph, etc, instead. Usually a modern scene will be represented via several specialized graphs (or flat lists!), not one of these traditional uber "scene graphs".

Thank you very much, I'm taking note.