Jump to content
  • Advertisement
Sign in to follow this  
algorhythmic

Scene Graph, Spatial Hierarchy separation

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

Hi, I've been reading up in past threads on scene graphs and it seems that most people agree that it should be built on logical relationships and no culling/collision/etc.. should be performed within. My question is therefore how does the scene graph tie in with efficient acceleration structures for rendering etc.. (octrees/bsp trees/whatever)? Thanks

Share this post


Link to post
Share on other sites
Advertisement
Well, fundamentally a scene graph is not tied to visibility. Consider one of the cliche examples, a solar system.

We have the root node of the solar system, which is the sun. All of the planets are children of the root and rotate around it. If the sun moves, their center of rotation changes accordingly, keeping them in the same relative spot. They also rotate around their own axes. Then, some of these planets have child moons that rotate around them, and move with the planets, which are busily circling the sun.

Now, it's pretty obvious that the visibility of the sun doesn't affect whether or not you can see any of the planets. It's mainly used for keeping coherent transformations, linking objects (for example, the wheels of a car), etc.

Spatial work can be completely independent. A fairly standard solution would be some sort of loose octree, or maybe an AABB tree.

The key here is that these two structures don't tie in together. First you apply the scene graph to update all of your objects, then you apply the spatial tree to determine visibility.


There are probably clever ways of linking the two, but I don't know any offhand.

Share this post


Link to post
Share on other sites
Basically yes, but you have to be aware that when you update the scenegraph then objects may move... meaning you then have to update the spatial system too.

Share this post


Link to post
Share on other sites
Here's a couple of threads from Yann that were linked on TripleBuffer. They make very interesting reads on this subject and offer some useful tidbits of information.

Need Help With SceneGraph/Octree concept

Terrain and SceneGraphs

They're quite lengthy so be prepared for a hearty read :)

EDIT: It seems from the post after this that you've already read them - ignore [rolleyes]

Share this post


Link to post
Share on other sites
are there any well-know clever techniques for making the two work together? I'm slowly trauling through Yann's threads about spatial hierarchies and scene graphs but so far nothing's jumping out at me :)

[EDIT] Many thanks evolutional, I was unaware of the TripleBuffer list. Much interesting Yann reading :) [/EDIT]

[Edited by - algorhythmic on September 12, 2004 2:11:47 PM]

Share this post


Link to post
Share on other sites
Heya, mind if I think out loud into this thread? :D

I started down this road just days ago myself, and have been doing a bit of reading on the subject (inclusive from those helpful threads).

It came to my attention as I got more of any idea of how a SG relates to the title I am working on at the moment I discovered that, for the most part, there's probably little advantage in implementing one at this point. The game I am working on is an overhead shooter of the form of Smash TV, so most of my entities won't be hierarchical at all. The exception being that I would like to add vehicles to the mix, so this requires an attachment mechanism between objects at the very least, but I can only ever see it going one level deep (two absolutely maximum).

I already have a full frame hierarchy implemented for animations and soon-to-be-implemented attachments - rather than make a vechicle attach to part of the frame hierarchy I'll probably include some attachment mechanism in the base object/node class to facilitate this.

I'm yet to determine if I should just go the whole hog and implement a scene graph however, as I've already implemented a frame hierarchy for animation, and in it's basic sense SG doesn't seem too far removed from this. I just don't want to get trapped by any 'gotchas' at a later date.

As for collision detection, I've implemented your standard quad/octree spatial partitioning scheme and I'll be using that for collisions by determining in what node an object lays and going from there, determining collision with other objects and the terrain itself.

Share this post


Link to post
Share on other sites
Nope, upon further research and reading Yanns article on SGs I've decided to just go ahead an write a simple one for now, I can increase it's functionality further in the future if need be. :)

Share this post


Link to post
Share on other sites
Unfortunately I'm not writting a game but a framework which I shall use to explore object interactions and so on within a virtual environment and so I'd like to have something relatively complete (at least a structure that I won't have to completely overhaul almost immediately).

There seem to be so many different interpretations of the concept that my head spins! One thread I was reading mentionned stressed their use to manage render state to as to optimise rendering by minimising state changes. Others look at scene graphs from a purely hierarchical point of view.

I'm lost. /me sobs!

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!