On 10/9/06, Jan Ciger <[EMAIL PROTECTED]> wrote:
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.
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.
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
-----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
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
