-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello,
Don Burns wrote: > The luxury we have with many graphics clusters is that we can impose a > master/slave architecture, where the slaves are simply readers. Only the > master writes to shared buffers, and the slaves simply receive the updates > at frame synchronization time. This is pretty much what I had in mind. The rendering slaves do not need to update the scene graph themselves, so it is a one-way affair simplifying the synchronization process quite a bit. > I think what you've described is a simple master-writer/slave-reader > architecture. Yes, I think that would be most appropriate for this case. > To make a humvee move, for > example, you call > > matrixTransform->setMatrix(matrix); > > where matrixTransform is the node that moves the vehicle and matrix is > where > the data containing the vehicle's position and attitude is stored for this > frame. In this case, 'matrix' can be allocated in the cluster's shared > memory pool (shared between nodes), but matrixTransform does not need to > be. This was what I was thinking about when I wrote about the ad-hoc solution. Is there a toolkit able to do this? (synchronize some sort of network shared memory). I guess that this is what VR Juggler does and I could probably find some more online as well. Probably even MPI could do. Do you have some preferred tool to do this sort of work? > Further, a simple update callback on matrixTransform can effect an > automatic update of the vehicle's position. You need only , then, > synchronize the shared buffers before calling the update traversal. Ah, neat. I didn't think about using the update callback to do this. Nice. > At the top level of the application then, running on the master, simply > updates the position of the vehicles, etc. synchronizes the shared buffers > and the positions are updated in graphics about a frame and a half later. > What about active stereo? Wouldn't this delay cause problems? AFAIK, for active stereo the rendering nodes have to be synchronized frame-by-frame, otherwise the stereo falls apart at the edges of the walls of the CAVE. I am sorry for these probably stupid questions but I didn't deal with a CAVE before and I would like to know from somebody more experienced what the problems could be. Regards, Jan - -- Jan Ciger GPG public key: http://www.keyserver.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFFKts8n11XseNj94gRAk8HAKC2uQLHDInGbB1qLBmX+iYY2ydXRwCdFYi7 oDtTIaV+yOlHUp+nTDNnPdU= =Vzj4 -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
