From: Angus Dorbie (dorbie++at++sgi.com)
Date: 01/18/2000 11:03:57
I'd say you are taking a chance with stereo because of the lack of
swapready.
It's imperative that you swap both eyes almost simultaneously or you'll
probably experience false (even impossible) depth cues and maybe cause
serious eye strain. Even frame locking is not going to be enough for
your application.
CHeers,ANgus.
Thomas Ruge wrote:
>
> 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
>
>
--
"It takes a vision to beat a vision."
-Thomas Sowell
This archive was generated by hypermail 2b29 : Tue Jan 18 2000 - 11:04:26 PST