Hello all,
I have a game I'm building and I'm debating whether or not to use a scene graph. I know for a fact that the scene graph, if I use one, will never be more than 1 level deep. What I like about having a scene graph in projects I've used in the past is that you can have an "SceneNode" interface which can implement separate rendering behavior for each type of thing that needs to be rendered. Additionally, the high level management of SceneNodes by a SceneManager class is also convenient. I like the scene graph design pattern as a whole, but I'm wondering if it's worth using it if the scene graph will only ever be one level deep. Is there another design pattern that is better suited for this situation? Or will a one level deep scene graph work out just fine?
Should I use a scene graph even if it will only ever be 1 level deep?
It will work, but it may be overkill, if you already have one implemented you might as well go ahead and use it, but if you have to write one I would skip it.
Implementing different rendering behaviors does not require a scene graph pattern, only a good design class in which you have a generic graphic object with all the basics and a specialized class for each different type of graphic to render, you can also turn the design upside down and have the graphic object own the rendering behavior as a property instead of implementing it in a specialized class.
In the end its a balancing problem, if your objective is just to get things working, use what you have or know how to do, even if its not the best, if your objective is to do things right, use only the appropriate tools to best fit the needs of the project.
Implementing different rendering behaviors does not require a scene graph pattern, only a good design class in which you have a generic graphic object with all the basics and a specialized class for each different type of graphic to render, you can also turn the design upside down and have the graphic object own the rendering behavior as a property instead of implementing it in a specialized class.
In the end its a balancing problem, if your objective is just to get things working, use what you have or know how to do, even if its not the best, if your objective is to do things right, use only the appropriate tools to best fit the needs of the project.
It may or may not be overkill. It can make pefect sense if you have a high
density of items in one area and a low one in another,
and if you are more likely to project some areas than other.
It's still a tree enabling you to prune items that you don't want to render,
but yeah, it depends. I wouldn't reorganize unless I really had to juice performance, though...
density of items in one area and a low one in another,
and if you are more likely to project some areas than other.
It's still a tree enabling you to prune items that you don't want to render,
but yeah, it depends. I wouldn't reorganize unless I really had to juice performance, though...
The benefit of a scene graph is having a nice hierarchy to manage your scene objects relative to each other. If everything is only 1 deep, then you might as well just have a list of objects and not worry about the graph.
Go over the list, do visibility checks, and if they pass, add them to the render list. You don't need a graph to have different rendering functionality.
Go over the list, do visibility checks, and if they pass, add them to the render list. You don't need a graph to have different rendering functionality.
The benefit of a scene graph is having a nice hierarchy to manage your scene objects relative to each other. If everything is only 1 deep, then you might as well just have a list of objects and not worry about the graph.
Go over the list, do visibility checks, and if they pass, add them to the render list. You don't need a graph to have different rendering functionality.
He might not as well; the scene graph, packing things together in common boundaries may save him visibility checks.
... Or am i missing something?
Depth 1 means no useful pruning, if the depth is 1, all objects will be checked for visibility, so there is no point, the only benefit of a depth 1 scenegraph is having a clean interface to manage objects
He might not as well; the scene graph, packing things together in common boundaries may save him visibility checks.
... Or am i missing something?
[/quote]
[quote name='Daaark' timestamp='1351872576' post='4996578']
The benefit of a scene graph is having a nice hierarchy to manage your scene objects relative to each other. If everything is only 1 deep, then you might as well just have a list of objects and not worry about the graph.
Go over the list, do visibility checks, and if they pass, add them to the render list. You don't need a graph to have different rendering functionality.
He might not as well; the scene graph, packing things together in common boundaries may save him visibility checks.
... Or am i missing something?
[/quote]
He might not as well; the scene graph, packing things together in common boundaries may save him visibility checks.
... Or am i missing something?
You can still use an acceleration structure (such as a kd-tree or a spatial-hash) to spatially partition your list of objects, but that's entirely different from an hierarchical scene graph.
Author
Thank you for the replies guys. I do not have anything that I can use so everything I'm building from scratch here. Given that, I will probably implement a SceneManager and SceneNodes, but not worry about any of the hierarchal stuff (i.e. all SceneNodes will be stored in a single list rather than a tree structure). Thank you again for the advice and suggestions.
Ah, ok. I thought for a moment that depth == 1 => two levels (0, 1)
With only one level, yeah no gain. Thanks!
With only one level, yeah no gain. Thanks!
He might not as well; the scene graph, packing things together in common boundaries may save him visibility checks.
... Or am i missing something?
Do visibility checks even belong in scene graphs? Seems like a workaround, I would always prefer an additional structure for acceleration.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement