gdalgorithms-list

[Algorithms] FW: [CsMain] Scene Graphs

[Aaron D. <ri...@ho...>]

I've read many discussions on this list as to the pro's and con's of various
solutions to storing, rendering and processing 3D objects but the
scene-graph hasn't really made much discussion since I've been subscribed.

I can't seem to find much on the web in regards to their usefulness apart
from a few papers on VRML and Java3D.

I'm having trouble seeing how the added cost of unnecessary traversal of
nodes and the memory overheads of parent/child links in a scene would be
worth the added effort but I'm curious as to the thoughts of the many
experienced developers on this list.

Do scene-graphs pay off?

If so, how?

Managing vertex buffers, textures, multiple instances of objects (with
shared vertex data), etc can get rather clumsy without a consistant system
yet everything I've read about scene-graphs suggests that they are simply
traversed and the objects in them rendered. How would I represent (say) an
octree implementation within a construct like
this?

- Aaron

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Jonathan W. <JW...@bi...>]

on 9/2/00 6:55 PM, Aaron Drew at ri...@ho... wrote:

> Managing vertex buffers, textures, multiple instances of objects (with
> shared vertex data), etc can get rather clumsy without a consistant system
> yet everything I've read about scene-graphs suggests that they are simply
> traversed and the objects in them rendered. How would I represent (say) an
> octree implementation within a construct like
> this?

The scene graph could just be thought of as a convenient logical structure
used to organise your data. It's actually more than just that (for example
it lends itself well to a portal based scheme or a hierarchical bone based
animation system). Keep the octree separate from your scene graph but have
it share the leaf nodes of your scene graph.

    Jon.

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Stephen J B. <sj...@li...>]

On Sun, 3 Sep 2000, Jonathan Wight wrote:

> on 9/2/00 6:55 PM, Aaron Drew at ri...@ho... wrote:
> 
> > Managing vertex buffers, textures, multiple instances of objects (with
> > shared vertex data), etc can get rather clumsy without a consistant system
> > yet everything I've read about scene-graphs suggests that they are simply
> > traversed and the objects in them rendered. How would I represent (say) an
> > octree implementation within a construct like
> > this?
> 
> The scene graph could just be thought of as a convenient logical structure
> used to organise your data. It's actually more than just that (for example
> it lends itself well to a portal based scheme or a hierarchical bone based
> animation system). Keep the octree separate from your scene graph but have
> it share the leaf nodes of your scene graph.
 
Or...

  Get a hold of a user-extensible scene graph and add Octree functionality
into it.  Since scene graphs are really well suited to object oriented
approaches, many are written in C++ which enables you to use class
inheritance to customise specific node types to your needs. Adding an
octree node type should be fairly easy in any decent SceneGraph API.

I wrote and support an OpenSource scene graph API that you might
find interesting - there are LOTS of others out there...

   http://plib.sourceforge.net/ssg

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] FW: [CsMain] Scene Graphs

[Scott L. <va...@be...>]

In my experience, flight sims, space shooters, and just about
any other external environment can benefit greatly from either
a plain old scene graph or some sort of minor extension to the
approach since there's relatively little occlusion and lots and
lots of offscreen and out of range culling.  I spent some time
last year considering how to write a portal engine within the
formalism and it seemed like they were apples and oranges
approaches to the same thing in that one is great with external
environments and the other is fantastic when there's lots of
occlusion.

There are some hybrid approaches for situations like dense
urban scenes involving lots of precalculation and bitmasks,
but those would waste a ton of memory if used in a situation
more appropriate for portals.

And that's my two cents and worth every penny!

Scott

RE: [Algorithms] FW: [CsMain] Scene Graphs

[Graham S. R. <gr...@se...>]

At SIGGRAPH 1999 there was a paper/panel session called "Scene Graphs: Wired
or Tired" to discuss this, although not necessarily from a game development
standpoint.

Here are a couple of links that should give you part of the content of that
presentation (if you don't have the SIGGRAPH proceedings already):

http://www.intrinsic.com/technology/presentations.htm
http://www.cs.brown.edu/research/graphics/research/siggraph99/scenegraph/

Graham Rhodes

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Aaron
> Drew
> Sent: Saturday, September 02, 2000 7:56 PM
> To: gda...@li...
> Subject: [Algorithms] FW: [CsMain] Scene Graphs
>
>
> I've read many discussions on this list as to the pro's and con's
> of various
> solutions to storing, rendering and processing 3D objects but the
> scene-graph hasn't really made much discussion since I've been subscribed.
>
> I can't seem to find much on the web in regards to their usefulness apart
> from a few papers on VRML and Java3D.
>
> I'm having trouble seeing how the added cost of unnecessary traversal of
> nodes and the memory overheads of parent/child links in a scene would be
> worth the added effort but I'm curious as to the thoughts of the many
> experienced developers on this list.
>
> Do scene-graphs pay off?
>
> If so, how?
>
> Managing vertex buffers, textures, multiple instances of objects (with
> shared vertex data), etc can get rather clumsy without a consistant system
> yet everything I've read about scene-graphs suggests that they are simply
> traversed and the objects in them rendered. How would I represent (say) an
> octree implementation within a construct like
> this?
>
> - Aaron
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>