On 17. May 2009, at 11:11, Robert Osfield wrote: > Hi Tim, > > On Sat, May 16, 2009 at 2:37 PM, Tim Moore <[email protected]> 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 _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
