and I know it distributes changes in the scenegraph, such as transforms, materials transparently...
Its called osgVR
http://www.nbi.dk/~gronager/osgVR.html
Now I know that Michael hasn't updated the code for a while, but this should certainly work as a good starting point on what you want Jan.
I use to have the same issues when we were discussing the clustering of some of our applications.
The problem in our apps were that the scenegraph itself was very dynamic both in terms of adding/removing nodes but also in change of transformations for many objects, interaction (events) etc...
So I felt a slight burden on explicitly "cluster" such an application, in comparison of writing one app, and just specifying where the renderingnodes were.
OpenSG has implemented clustering on a broad level. The whole scenegraph is designed for parallellism. That was an early decision from them. That also had a large impact on the usability and the complexity of the code, whenever a part of the scene is changed it is copied and the copies has to be syncronized, a lot of work.
But they had particle examples running on dozens of machines with 20.000 particles all updated on one machine and reflected without any explicit distributioncode in the app...
I said in the beginning we had some issues with the thought of having to do explicit clustering, but now with Quad DualCore, multiGPU machines, who needs clustering?
I told myself in the beginning of 2001, dont do clustering, just wait for the next generation onyx, and now they are here!
For a small sub-fraction of the price :-)
/Anders
On 10/10/06, Don Burns <[EMAIL PROTECTED]> wrote:
Hi Jan,On 10/9/06, Jan Ciger < [EMAIL PROTECTED]> wrote:-----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?
I'm afraid I cut my teeth on low level network programming and most tools feel like overkill for this kind of application. The osgcluster example was written by an example I gave Robert a while back and is very simple. In this case, it sends nothing more than the eyepoint. But how much data you send is just a matter of data size.
UDP (DATAGRAM) packets can send up to a configurable (and queriable) amount of data per packet. (I think the default is around 1540 bytes, or something like that). In the simple case, your data can fit into one packet, which can be sent every frame (about 12 double matricies, or 24 single precision matrices).
Anyway, for me, this is such low hanging fruit that I just do the simple (some times adhoc) method. In fact, a solution could have been written in about the time it takes to write this email thread.
> 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.
This actually becomes a hardware video sync problem. It really is a different level of synchronization than the data sync. I cover some of that in this article:
http://www.donburns.net/OSG/Articles/Synchronization/
What I don't cover in the article is the issue of stereo. In an active stereo system, I believe the issue is one of synchronizing drawing to the first buffer (left back, or right back) with data. That is, the data need only update once for every two "subframes" of stereo.
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.
THe only stupid question is the one not asked. :) Of course, I don't know what excuse I might have if I've provided any stupid answers.
-don
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/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
________________________________________________________________
Anders Backman Email: [EMAIL PROTECTED]
HPC2N/VRlab Phone: +46 (0)90-786 9936
Umea university Cellular: +46 (0)70-392 64 67
S-901 87 UMEA SWEDEN Fax: +46 90-786 6126
http://www.cs.umu.se/~andersb
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
