[vtkusers] CrystalEyes stereo on an SGI Prism

[Jens Thomas]

Hi Michael,

Michael Scarpa wrote:
> Jens,
>
> On Wed, Jun 28, 2006 at 04:24:21PM +0100, Jens Thomas wrote:
>   
>> Hi Michael,
>>
>> Michael Scarpa wrote:
>>     
>>> Jens,
>>>
>>> On Wed, Jun 28, 2006 at 03:29:07PM +0100, Jens Thomas wrote:
>>>  
>>>       
>>>> Currently, when I try it, I get the following message:
>>>>
>>>> Adjusting stereo mode on a window that does not support stereo type 
>>>> CrystalEyes is not possible.
>>>>    
>>>>         
>>> Are you making sure that the render window you create is capable of
>>> producing stereo images?  If I'm not mistaken, you have to call
>>> vtkRenderWindow::StereoCapableWindowOn() (see VTK online documentation
>>> for details) *before* any rendering is done.  Otherwise VTK complains if
>>> you try to activate stereo rendering, because by default it does not
>>> create a stereo-capable window.  I hope this helps!
>>>       
>> I think I'm getting this bit right, because if I change the 
>> SetStereoTypeToCrystalEyes call to SetStereoTypeToRedBlue, then I get 
>> Red/Blue stereo rendering, so I think I've correctly enabled the stereo 
>> capability for the vtkRenderWindow.
>>     
>
> I've just tried it out.  As a matter of fact, I have found the following
> behaviour on our test machine here:
> If I call vtkRenderWindow::SetStereoOn() *without* a prior call to
> neither vtkRenderWindow::StereoCapableWindowOn() nor
> vtkRenderWindow::StereoRenderOn(), I do indeed get correct red/blue
> stereo rendering.  But, if I add a call to
> vtkRenderWindow::SetStereoTypeToCrystalEyes() *before* the call to
> StereoRenderOn(), I do indeed get the error message you quote.  The
> solution here was to put a call to StereoCapableWindowOn *before* the
> first rendering (e.g. before starting the other calls).
>
> Curiously enough, if instead I move the call to
> SetStereoTypeToCrystalEyes() to *after* the call to StereoRenderOn(), I
> do *not* get any error message, but I also don't get any stereo
> rendering.
>
> So the solution to your problem might still be a missing call to
> StereoCapableWindowOn().  As far as I know, this will make sure that the
> proper window is created with the proper OpenGL bits set to allocate a
> left and a right eye buffer, etc.  In case of red/blue stereo, these
> settings are not necessary, and so VTK does not complain.
>   
I was reasonably sure that the window is being created correctly and 
that I just need to configure the SGI prism correctly for the two 
projectors. However, I'm now starting to have my doubts, as there is 
something strange going on with the way the window is being created.

My program is written in Python/Tk, and I create the renderwindow with a 
call to vtkTkRenderWidget with the stereo flag set to on. In the 
vtkRenderWidget code, it creates the renderwindow and calls 
StereoCapableWindowOn(), and if I get the renderwindow to print itself 
straight after this, I see the following:

vtkXOpenGLRenderWindow (0x85c6670)
  Debug: Off
  Modified Time: 2132
  Reference Count: 2
  Registered Events: (none)
  Erase: On
  Window Name: Visualization Toolkit - OpenGL
  Position: (0, 0)
  Size: (0, 0)
  Mapped: 0
  OffScreenRendering: 0
  Double Buffered: 1
  DPI: 120
  TileScale: (1, 1)
  TileViewport: (0, 0, 1, 1)
  Borders: On
  IsPicking: Off
  Double Buffer: On
  Full Screen: Off
  Renderers:
    Debug: Off
    Modified Time: 2130
    Reference Count: 1
    Registered Events: (none)
    Number Of Items: 0
  Stereo Capable Window Requested: Yes
  Stereo Render: Off
  Point Smoothing: Off
  Line Smoothing: Off
  Polygon Smoothing: Off
  Anti Aliased Frames: 0
  Abort Render: 0
  Current Cursor: 0
  Desired Update Rate: 0.0001
  Focal Depth Frames: 0
  In Abort Check: 0
  NeverRendered: 1
  Interactor: 0
  Motion Blur Frames: 0
  Swap Buffers: On
  Stereo Type: RedBlue
  Number of Layers: 1
  AccumulationBuffer Size 0
  AlphaBitPlanes: Off
  AnaglyphColorSaturation: 0.65
  AnaglyphColorMask: 4 , 3
  MultiSamples: 8
  ContextId: 0
  Color Map: 0
  Display Id: 0x85c9090
  Next Window Id: 0
  Window Id: 0

In my program, I then get the renderwindow from the widget via a call to 
GetRenderWindow(), and then set the stereo options with calls to 
SetStereoTypeToCrystalEyes() and StereoRenderOn(). When I get the 
renderwidget to print itself then, I get the following:

vtkXOpenGLRenderWindow (0x85c6670)
  Debug: Off
  Modified Time: 2156
  Reference Count: 3
  Registered Events: (none)
  Erase: On
  Window Name: Visualization Toolkit - OpenGL
  Position: (0, 0)
  Size: (400, 400)
  Mapped: 1
  OffScreenRendering: 0
  Double Buffered: 1
  DPI: 120
  TileScale: (1, 1)
  TileViewport: (0, 0, 1, 1)
  Borders: On
  IsPicking: Off
  Double Buffer: On
  Full Screen: Off
  Renderers:
    Debug: Off
    Modified Time: 2130
    Reference Count: 1
    Registered Events: (none)
    Number Of Items: 0
  Stereo Capable Window Requested: No
  Stereo Render: Off
  Point Smoothing: Off
  Line Smoothing: Off
  Polygon Smoothing: Off
  Anti Aliased Frames: 0
  Abort Render: 0
  Current Cursor: 0
  Desired Update Rate: 0.0001
  Focal Depth Frames: 0
  In Abort Check: 0
  NeverRendered: 0
  Interactor: 0
  Motion Blur Frames: 0
  Swap Buffers: On
  Stereo Type: CrystalEyes
  Number of Layers: 1
  AccumulationBuffer Size 0
  AlphaBitPlanes: Off
  AnaglyphColorSaturation: 0.65
  AnaglyphColorMask: 4 , 3
  MultiSamples: 8
  ContextId: 0x85d2df8
  Color Map: 46137581
  Display Id: 0x8366118
  Next Window Id: 0
  Window Id: 46137582

As you can see, although the address of the window (0x85c6670) is the 
same in both cases, the first is stereo capable and the second is not 
and they also have different display and window id's, and when I print 
the python id of the two windows, they are different, which suggests 
that they are different objects.

What this means, I'm not entirely sure...

Best wishes,

Jens