Jump to content
  • Advertisement
Sign in to follow this  

meta-hierarchies, scene-graphs + spatial data structures, critique my design

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

I would like some opinions/advice/critique on the design structure of my scene graph, high-lighting any flaws i may have over-seen will be greatly appreciated. My main problem as you can guess is integrating/using SGs & spatial data structures together effectively & efficently. I have thought out 3 solutions i like some advice as to which would be the most effective one, highlight the dis/advangtages, i think this thread would also be useful to others aswell. I will show the overall design in a highly simplified & incomplete form to focus on the main structure and/or problem, think of it as a more of a conceptual design, i've used UML class diagram so i hope people can understand it, if you need more info just ask and i'll fill the void. For spatial data structures i'll use a kd-tree as just an example, in theory any and most if not all spatial DS can be integrated/used/replaced in this scene graph structure as it kind of follows the paper on meta-hierarchies using design patterns to help out of course [smile]. 1. First one seems to be simillar to how most graphics engines do it: To me how-ever this seems kind of strange thing to do as it messess with the actual structure of the scene graph in a non-sensical manner and would probably require alot of updating maintance at run-time, the main advantage i see it provide is some uniformaity. 2. Next one is to only allow leaf nodes to be encoded in a spatial data structure but it keeps the scene graph and spatial data structure separate. The only disadvantage i can see is you've lost all uniformaity. 3. Last but no least i think i found away to "have my cake & eat too" This solution is kind of decorator pattern but instead of containing and delegating most operations to the component type (abstract node) it does it directly with geo_nodes only. It also contains the whole spatial data structure in a single leaf. The third solution seems to be the one for me.

Share this post

Link to post
Share on other sites
Hey snk_kid!

Just wanted to say that it's a great idea that you pulled this design here, maybe if someone experienced would post a critique or two we could have the
Scenegraph topics done once and for all ;)

I think your third option seems to be the way to go, I actually am doing a similar design... though I'm currently trying to implement ABT spatiol structure instead of the KD tree. Though it doesnt matter, as long as it implements the Spatial node, just as you described.

And I'm actually not using a decorator for the Spatial node, seems like you tie your spatial node to the geo_node. I would leave it open, since cameras and other stuff might benefit from a spatial structure even though they aren't geometry types.

I also noticed that you have the bounding volume incorporated into the abstract_node. Myself I use the visitor pattern to visit all the BoundinVolume classes in the tree instead. Actually I use a generic Visitor pattern with a dynamic_cast, maybe a tad slower... but hella nicer design:

CollectRenderables : Visitor<Renderable> {
/* Inherited visit:
void Visit(Node node) {
Renderable* pRenderable = dynamic_cast<Renderable*>(node);
if(pRenderable) {

virtual void Visit(Renderable* pRenderable) {

And I like your design with the composite pattern, think thats the way to go ;)
Instancing is also a nice feature, which doesn't mean each node needs multiple parents... each node still has only one parent but enhanced with an Internal node. I Think thats great.

Anyway, just wanted to bump this thread up again ;)
Maybe this time ppl will make a discussion of this, since this is probabilly
something many ppl have problems with.

c ya

Share this post

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

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!