From: Thomas Ruge (Thomas.Ruge++at++gmx.de)
Date: 01/15/2000 04:32:57
Don Burns wrote:
> Well, since my name's been mentioned...
>
> Synchronization of multiple views amongst loosely coupled systems is really a
> real-time issue. The better the method the better the quality.
>
> The demo mentioned was shown at IITSEC this year and employed the simplest
> method. It was simply a one-way update of eyepoint, broadcast to anyone on the
> network who cared to listen. The UDP packets (simply no need for TCP, too
> slow, too much latency and unecessesary contention of the network bandwidth)
> were sent at a constant rate, which is faster than the graphics was updating.
> During the APP phase (single proc Performer on Linux), on each of the
> recieving systems, the queue is emptied and the final value used for XYZ, HPR.
> This provides a reasonable (should we say "good enough" in some cases) method
> of synchornizing the eye point to within about a frame or two of each other.
>
> For applications that don't use contiguous viewing channels that will be
> displayed side by side, this can be fine. It would be stretch to call this
> truly synchronized, however. If displayed side-by-side, the disparity of frame
> synchronization is actually quite apparant.
>
> The next form of synchronization is to use frame-lock. An external
> synchronization source can be used to keep vertical retrace on multiple systems
> in step. This is sometimes mistakenly referred to as genlock. (Genlock synchs
> the entire signal - vertical and horizontal). This can be used in conjunction
> with the network broadcasting method to attempt to keep all eyepoints
> refreshing the screen at the same time. Some two-way traffic may be necessary
> to insure that all channels have the same eyepoint for the current frame. This
> depends also on the graphics hardware's capability to swap buffers on vertical
> retrace.
>
> It seems that some of the PC hardware has become caught up in chest thumping
> about how fast they can run Quake, measure purely on a frames per second basis.
> To exceed 60 hz, the block on vertical retrace is not used and thus the
> graphics may sometimes swap buffers in the middle of a vertical retrace. This
> can cause anomolies such as "tearing". Unless you can block on vertical
> retrace, there is little frame-lock can do for you.
>
> A swap ready signal can also be used in conjunction with either a genlock or
> frame lock signal. This provides one more step for insuring that the same
> frame is displayed on all channels at any given moment.
>
> -don
>
> PS. Not sure this all has a true bearing on the subject (clustering), but it
> is interesting for visual simulation.
Hello Don,
this was exactly the information i was looking for. We are looking for
possibilities to get passive stereo applications
running with 2 projectors ( using polarization filters ). Are you working on this
problems ? Will you have a demonstration
of your cluster this year ?
Thomas
-- ------------------------------------------------------------------------- Thomas Ruge, Siemens Virtual Reality Center private email: Thomas.Ruge++at++gmx.de
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 04:30:31 PST