Changing stereo-related flags

Development
1

Currently there are 3 user-settable flags that affect whether and how vtkRenderWindow does stereo rendering: StereoCapableWindow, StereoRender and StereoType. All are user settable and the biggest annoyance is that there’s an implicit order in which these flags need to be set for things to work e.g. vtkRenderWindow::SetStereoRender will ignore the requested value if this->StereoCapableWindow==false && this->StereoType == VTK_STEREO_CRYSTAL_EYES.

Thus assuming an active stereo capable environment, the following will fail:

renWin->SetStereoTypeToCrystalEyes();
renWin->StereoRenderOn(); /* gets ignored, generates warning */
renWin->StereoCapableWindowOn();

however, the following will pass:

renWin->StereoRenderOn(); /* successful */
renWin->StereoCapableWindowOn();
renWin->SetStereoTypeToCrystalEyes();

or the following too:

renWin->StereoCapableWindowOn();
renWin->SetStereoTypeToCrystalEyes();
renWin->StereoRenderOn(); /* successful */

My proposal is as follows:

  1. make StereoCapableWindow a get-only variable. The SetStereoCapableWindow API will become protected. Subclasses that create the OpenGL context can toggle the flag based on whether the context is stereo capable or not.
  2. SetStereoRender flag will never ignore the value being set by the user. The StereoRender ivar is what subclasses will use to create a context, if appropriate. If they can’t create a stereo context, they simply set StereoCapableWindow flag to false.
  3. When doing the rendering, vtkRenderWindow will do active-stereo rendering only of StereoRender == true && StereoCapableWindow == true && StereoType==VTK_STEREO_CRYSTAL_EYES. If VTK_STEREO_CRYSTAL_EYES was requested by StereoCapableWindow == false, we will generate a warning once.
1 Like
2

Sounds reasonable to me. The ordering of the calls should not give different results.

3

+1

4

I’ll create an MR. I may opt for a new var name instead of StereoCapableWindow just so that there is clear distinction between old usage and the new.