From: Bram Stolk (
Date: Wed Nov 09 2005 - 04:51:10 CST

John Stone wrote:
> Bram,
> If you're running with separate projectors for each eye, then I'm
> almost certain you're experiencing a race condition. I've seen it before

Nope, it's not a race condition: this would be impossible, as the
app is multi-process, and not multi-threaded. The shared resources
between the processes are minimal: They all have there own graphics pipe.
I don't think there is a shared resource that the processes write to,
so race-conditions are not possible.

It turned out to be exactly like I suspected: lights are off for one eye.
This is because the code in Scene.C tries to do lazy setting of lights:
Only call GL cmds if the lights changed.
This is hazardous in stereo setups: if lights change, you need to make
the GL calls for all eyes, for all walls in a cave.
If fixed this in a one-liner in Scene.C but CVS didn't allow me to
commit it:

bram_at_vger:~/src/vmd/vmd/src$ vmdcvs diff Scene.C
Index: Scene.C
RCS file: /vmd/cvsroot/vmd/src/Scene.C,v
retrieving revision 1.65
diff -r1.65 Scene.C
< if (light_changed) {

 >   if (light_changed || !strcmp(display->name,"Cave")) {
bram_at_vger:~/src/vmd/vmd/src$ vmdcvs commit -m "Fixed L/R lighting anomaly in CA
VE mode" Scene.C
cvs [server aborted]: "commit" requires write access to the repository
If you give me write access, I'll commit it for you, or else you would
have to commit yourself. Write access could be handy if I stumble onto
more problems.
Also note: against a tiny performance penalty, you could opt for sending
lighting cmds each frame, and scrap the light_changed mechanism. I think
that FreeVR thing, and other stereo setups may suffer as well from this.
    Bram Stolk
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000
"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
  operating system originally coded for a 4-bit microprocessor by a 2-bit
  company that can't stand 1 bit of competition."