On 17. May 2009, at 11:11, Robert Osfield wrote:

Hi Tim,

On Sat, May 16, 2009 at 2:37 PM, Tim Moore <timo...@redhat.com> wrote:
I've been thinking about this too, but without the global cull. Are you
trying to avoid having a real scene graph on the local nodes and keep
lists of drawables and StateSets instead? I would think that broadcasting
the dynamic changes to the scene graph would result in less network
traffic than broadcasting lists of drawables, but I suppose it depends
very much on the application.

A fully distributed scene graph would probably be more efficient that
a distributed render graph approach, but it'd be more intrusive to the
scene graph design and implementation as all nodes would need an
fomarlised update mechanism.  OpenSG has such support but is a more
complicated object model than the OSG, which makes it more involved to
use and extend than the OSG.

In fact the only thing needed for this is a change notification mechanism. The distribution can build a 'shadow' hierarchy, and update the remote copies based on the notifications.

The update mechanism and serialization can live outside the scene graph.


The distributed render graph approach is lighter weight as you are
only tracking changes to the drawable leaves and state which is more
constrained and well encapsulated than other parts of the scene graph.
I believe it'll be much easier to implement this approach in a non
intrusive way than a full blow distributed scene graph, which is
really why I suggest it, we'd be able to get much of scalability of
the cluster without the complexity that normally comes with doing a
distributed application or distributed scene graph.

I'm wondering what the network load of such a distribution would be, and how one could cache the data. The beauty of the distributed scene graph is that on a static scene virtually no data has to be transmitted. It seems to me that the distributed render graph at least needs to transmit the equivalent of display list ID's.

FYI: The Equalizer source tree has an example of an OSG/Eq integration relying on a shared filesystem to load the SG. We are thinking of extending this example (and OSG) towards using a distributed OSG, pending on time/financing.


Best,

Stefan.

--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to