-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Don Burns wrote:
>> I'm afraid I cut my teeth on low level network programming and most tools
>> feel like overkill for this kind of application.
<..snip..>
> 
>> 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.

I agree, I have no issues with writing low-level code like that (and
have done so many times) however this sort of solution has two problems:

- - It is difficult to get all the nasty corner cases right (packet
defragmentation, dropped connections, retransmits, etc.)

- - It is difficult to "sell" it to people used to big buzzwords and huge
frameworks - believe me or not - we had to build a simulator which was
passing huge chunks of XML around for hundreds of simulated humans just
to update their positions - an "enterprise" solution, indeed. You could
probably imagine the performance - 90% of time was spent parsing XML.

That's why I was asking whether there are some commonly used libraries
for this - both to ease the pain of the low-level coding and to make it
more digestible for the others involved.

>> 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/

Nice summary, thanks for the link.

>> 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.

That makes sense - you push one data frame out, render two frames (left
and right) and then push (and synchronize) another data frame out.

Thanks for the information, I have to check how they are actually
driving the CAVE at the moment and then we make a decision how to
proceed with this.

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

iD8DBQFFK9x3n11XseNj94gRAiaLAJ4wab4K317OGBdhQVFh2wUNdNzqkACfa/3b
hezOVTdtIEwjePCYZfIJzVg=
=dEvg
-----END PGP SIGNATURE-----
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to