VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu Jun 12 2003 - 11:24:51 CDT

Hi,
  See the other note I just sent about determining which kind of
stereo bug this "double image" is. I have a couple other comments
however:

On Thu, Jun 12, 2003 at 06:02:01PM +0200, Bogdan Costescu wrote:
> > One thing you may wish to try would be to run one of the last test versions
> > of VMD 1.8.1 with the "VMDPREFERSTEREO" environment variable.
>
> I described a bit my setup in the old message. I'll just add that I've
> used the latest version at that time of the NVidia driver and VMD
> alpha/beta version which supported "VMDPREFERSTEREO" - with the NVidia
> drivers, setting this variable is a must. I did not try other
> stereo-capable OpenGL programs.

The NVidia drivers are incapable (at present) of providing both
antialiasing and stereoscopic rendering. That's why this code was
added. Until they improve their video drivers and/or hardware to
support both features simultaneously, this environment variable is a must.
High-end graphics workstations like Sun and SGI machines have supported
multisample antialiasing and stereo simultaneously for several years
now, so I suspect the PC video boards will get there eventually, the
problem is that until "Quake" or the other popular games out there use
these features, they are very low on the priority list. NVidia and ATI
are driven by games, not by science, unfortunately. I think its just
a matter of time. They'll keep improving the hardware as time goes on.

> But in my (pretty limited) testing, I did not observe the same effect when
> not using the stereo enabler (the Quadro card that I've used offered me
> the option of connecting the IR emitter directly...)
>
> > Its possible that the XiG drivers
>
> Yeah, but NVidia drivers too ? Until Dr. White's message, I thought that
> the glitches that I've seen come from the NVidia driver when set for
> "Blueline" mode. Being only 2 cases now, I can still consider this being
> a coincidence, but it lets me wondering if something else (maybe a
> combination of factors) is the root of the problem...

Well, be aware that "blue line stereo" is, and always has been, a hack. :-)
It works by outputting a special video signal in the "overscan" area of the
video image, outside of what you'd normally see on the display. This method
can be finicky since the timing is dependent on the video mode in use
(pixel clocks are different when you run at different resolutions, etc.)
The emitter box picks up this "blue line" and uses it to determine which
eye is currently being displayed on the CRT.

If "blue line" stereo gives you problems, but using the VESA stereo
conector on the same machine works, that essentially proves that
the problem is in the video driver or in the emitter hardware, or
a combination of the two. The application doesn't know anything about
how the stereo signal is being synchronized, all it knows is that it
has to draw two color buffers, one for left, and one for right, and
then it tells OpenGL to display them by calling glXSwapBuffers().
Once glXSwapBuffers() has been called, its up to the video driver
and the hardware to correctly display the rendered images. The hardware
takes care of swapping the left/right images and synchronizing shutter
glasses from that point on.

  John Stone
  vmd_at_ks.uiuc.edu 

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078