Sign in to follow this  
DEADC0DE

scenegraph vs components

Recommended Posts

DEADC0DE    106
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<Updateable*>, 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 :D

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

Share this post


Link to post
Share on other sites
Krohm    5030
[font="arial, verdana, tahoma, sans-serif"][size="2"]This should probably be moved in SW Engineering, it's definetly not a game design thread.
Saying that "[i]scenegraphs are outdated and shouldn't be used any more[/i]" 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.[/size][/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?

[quote name='DEADC0DE' timestamp='1309009425' post='4827568']1. classic scenegraph (I don't see any advantages in that)[/quote]You don't see any advantage compared to what? According to what metric?

[quote name='DEADC0DE' timestamp='1309009425' post='4827568']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?)[/quote]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!

Share this post


Link to post
Share on other sites
Burnt_Fyr    1665
[quote name='DEADC0DE' timestamp='1309009425' post='4827568']
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<Updateable*>, 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 :D

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! :)
[/quote]

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.

Share this post


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

Share this post


Link to post
Share on other sites
Hodgman    51238
[quote name='DEADC0DE' timestamp='1309022989' post='4827634']
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?[/quote]Well, when implementing an interface (e[i].g. [font="Courier New"]IUpdatable[/font][/i]), 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:[code]class Animation : public IUpdatable { void Update() { DoAnimation(); } void DoAnimation(); };
class Monster : public IUpdatable { void Update() { DoAI(); } void DoAI(); };

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

std::vector<Animation> animations;
std::vector<Monster> monsters;
for(...)
animations[i].DoAnimation();
for(...)
monsters[i].DoAI();[/code]

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. ([i]N.B. this isn't real code -- just trying to get some ideas across[/i])[code]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;

};[/code]

Share this post


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

Share this post


Link to post
Share on other sites
Krohm    5030
[quote name='Hodgman' timestamp='1309016810' post='4827605']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" [i]are [/i]outdated junk for modern games. There used to be a lot of them, and now they're not very popular ([i]because they're evil[/i]). [url="http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D"]Here's a not too old rant about them[/url].

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 [i]several [/i]specialized graphs (or flat lists!), not one of these traditional uber "scene graphs". [/quote]Thank you very much, I'm taking note.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this