# Thread: Recursive techniques for scene graphs

1. ## Recursive techniques for scene graphs

Anyone who know any good papers on recursive scene graphs ?

Some thoughts of mine..

When creating e.g. a tree. Would you need a switch behaviour to switch in different node paths depending of recursion level.

When building a graph, would you need recursive levels of recursive contents. e.g. kind of stack of recursive contents.. e.g. to create recursive leaves as a child of a recursive branch..

When rendering 10.000 (just a big number) recursive nodes, would you recurse each node at a time or would you recurse each node in a pass in parallell. I guess you could limit state switches if you did the latter..

2. ## Re: Recursive techniques for scene graphs

Well that went down like a lead balloon, didn't it tooltech?

3. ## Re: Recursive techniques for scene graphs

Well. Pretty boring topic I guess ;-)

4. ## Re: Recursive techniques for scene graphs

Tooltech, just out of interest, do you use your scenegraph traversals for culling, collision and state changes?
If you do, then you're not going to get good performance - scenegraphs are only good for representing hiearchical coordinate systems, they're no good for culling, no good for state management, no good for collision detection - they're a coordinate hiearchy, not a spacial hiearchy, therefore are not the right tool for the job.
The only recursion down your scenegraph you should be doing is to update absolute transforms.

5. ## Re: Recursive techniques for scene graphs

Well. I get very good performance anyway ;-)

I use it for culling,traversal, rendering, collision detection etc...

6. ## Re: Recursive techniques for scene graphs

What do you mean it is not good for spatial info ? It is very good for that in my oppinion...

7. ## Re: Recursive techniques for scene graphs

How is it good?
How do you build your scenes? Do you build them with a spacial criteria, or a render state criteria? Do you take in a poly soup and spacially sort your scenegraph?

8. ## Re: Recursive techniques for scene graphs

You use it for collision? Tri-to-tri? Ray-to-tri?
You have a geonode (or whatever you call them) containing a huge mesh (500>tris)....you check your tri/ray with every triangle? Even if you select the lowest LOD, it's still going to give bad performance.
My point is, scenegraphs are good for some things, but really quite slow and awkward for others. A unified approach is needed - get your coordinate system data from your scenegraph (and other inherited properties), get your state changes from your shader state block, get your collision info from a quadtree/octree/bsp depending on the type of scene you're rendering (bsp for highly occluded scenes etc.).

9. ## Re: Recursive techniques for scene graphs

The big chunk of geometry in your example is in my oppinion one special case of geometry. The scene graph detects the boundary of the geometry and then lets the actual geometry decide what it hits. That procedure is in your specific case a octree, but could be other methods for other geometries like high level surfaces etc. Very clean design. Scene graph is great for that..

State changes is for rendering purpose. The scene graph does traversal and the rendering pipeline optimizes for state changes. Scene graph does optimis like same state for multiple instances of data etc. minmal state changes between hierarchy nodes etc. very good for that purpose. Dont mix with rendering state sorting.

10. ## Re: Recursive techniques for scene graphs

That's really confusing. Isn't an octree a scene graph ? If not, what's your definition of a scene graph ? If it is, i fail to see how it's bad for culling for example..

Y.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•