active stereo and ParaView

I’ve been playing with stereo support in ParaView for sometime now and here are some ideas to improve the UX. I wanted to get a feel for what people think.

  1. ParaView Qt client will always attempt to create an active-stereo-capable context. If not supported on system, then the Crystal Eyes stereo mode will not be shown in the UI. This enables/implies the following:
    i. paraview --stereo will no longer be needed or supported.
    ii. Stereo rendering can be enabled/disabled by simply clicking on a toolbar button. The button can show a drop-down menu to enable choosing the stereo type e.g. anaglyph, red/blue, etc. This button may only affect the active view or all views. It seems reasonable to me to affect all views since if you’re wearing stereo glasses, I’d expect you’d be wearing them when looking at any of the views and not just the active one – but we could go either way.
    iii paraview --stereo-type=[type] is same as using the toolbar button to change stereo mode except via command line.
    iv. Changing stereo mode using the tool button will only affect the Qt application. It won’t get saved in state files etc.
  2. pvpython and pvbatch will continue to support --stereo-type=[type] arguments which will act as standin for the toolbar button shown in the Qt client for the same effect. Note, here too, --stereo argument is no longer necessary or supported.
  3. pvserver and pvrenderserver will support --stereo-type=[type], however it will only be relevant and used in cases where the server displays results to the user i.e. tile-display mode and CAVE mode. For conventional client-server mode were the final rendering results are shown in the Qt client (or pvpython), the server processes don’t need this argument since the client will drive the stereo mode.

Thoughts?

Excellent. Jeff M. should be consulted before implementing. Jeff understands the math for the interocular distance between eyes, and the interplay with the distance to the screen (whether a monitor, or power wall).

Good changes I think. Exposing the eye settings in the gui would be nice - I found them in python though. I’d like to here more from Jeff M on the math for interocular distance (and angle). I’ve made some guesses on it once I made a stereo movie that made me cross-eyed, but would like to know the smart way to do it.

ParaView 5.7 will include an eye angle option in the Adjust Camera dialog which should help with this. But I agree, may be we need a separate discussion on how to setup a stereo environment correctly.

image

1 Like

My guess at doing this right was to figure out my distance from the object (camera position), and then set an eye separation that would give some good depth effect, and then set the eye angle so that both eyes would focus on the object. I.e. R*angle(radians) = eye separation.

I’m over my head with Stereo, and Jeff is out today. Will wait for his brilliant answers.

Hi Utkarsh,

This sounds like a great idea. I just checked with our CAVE-system (the YURT) and at the moment we start the client with Stereo Eyes. It always seemed a little bit strange as the machine we start the client does not support stereo. But as the stereo mode was propagated to the server, this was the only way to get stereo working. Only setting it for the server and not the UI would be great and seems more logical.

PS: When do you think the stereo-type flag will be available on the server side for testing? I just checked and did not see it.

Best,
Ben

Ben, I haven’t gotten around to implementing this proposal yet. Glad to hear that folks are in general agreement with the proposed approach.

Hi Utkarsh

Ben reports that the new version of paraview seems to have broken stereo rendering for us. It seems like there is some mismatch between where stereo needs to be specified and where there are options to do so? Ben might have more info if this doesn’t describe the problem sufficiently.

Thanks!
-David

Additional info will definitely be helpful. I can never keep track of what config who is using so exact steps that I should do locally to reproduce the issue is always helpful.

Hi Utkarsh,

When testing the latest change for immersive Volumerendering in the YURT about 2 months ago we had to use the the newest paraview source. The options to use stereo (–stereo --stereo-type=‘Crystal
Eyes’) did not exist on the client anymore. We therefore checked the server and they existed there as you suggested in your change. However it seemed as if stereo was still not working when we added
them to the pvserver command. We also have to use the flag “–disable-xdisplay-test” so I am not sure if this caused the issues or if we need to add some other commands. Also was at that time the change fully implemented or did you still apply changes after beginning of August. Any help would be appreciated.

Thanks and Best,

Ben

@Benjamin_Knorlein, can you provide the exact version of the ParaView source you’re using? paraview --version should indicate that. ./bin/paraview --stereo --stereo-type="Crystal Eyes is still supported, so I am not sure what errors you were encountering with it. Note the discussion on this thread is for a new proposal that is not implemented yet. To avoid confusion, I’d highly recommend starting a new thread with issues that you’re encountering with stereo.

@utkarsh.ayachit, as i previously said we had to use the newest source from the github repo to test a fix for immersive volume rendering in our CAVE system. I saw that there are already some changes for this proposal on it, .e.g commit ccccacc7fa20ada7ed19c36b1de6b571fcda9fe6 be smart about stereo type, so I assume it is better to add it to this thread And paraview --version gives me : paraview version 5.7.0-RC1-196-gc5553e1.

Thanks. Ben

cccacc7 is not this proposal. I’d recommend using paraview --stereo --stereo-type=".." and try again. Currently --stereo needs to be specified on the client for it to work. In otherwords, there are no changes from what you were previously doing so stick with the same arguments.

@utkarsh.ayachit @kmilo9999 I just talked to Camilo and apparently we already patch it for our rendering, so it might be that it got broken on our end. We will download the newest version and test again without our patch. We will let you know.
Best,
Ben