Hello, I am the one who requested the changes, they were made to correct the stereo separation with working with zSpace hardware for data that was small in size (floating point values of coordinates, >> 1, for example data that ranged from 0.0000000 to 0.0000001 I checked its use with data across 13 orders of magnitude from data of size 1,000,000 to data of scale 1/1,000,000. I admit my fix is an approximation, but I am attempting to get a reasonable agreement of size with the non stereo operation
double eyeSeparationCorrectionFactor = 10.0; double shiftDistance = this->EyeSeparation / (2.0 * eyeSeparationCorrectionFactor); if(this->Distance < 1.0) { shiftDistance *= this->Distance; } // Front (aka near) double F = E[2] - (this->Distance + this->Thickness);//E[2] - 10000.0;//this->ClippingRange[1]; // Back (aka far) double nearDistanceCorrectionFactor = 1000.0; double B = E[2] - (this->Distance / nearDistanceCorrectionFactor);//E[2] - .1;//this->ClippingRange[0]; Without these changes with small data the stereo separation is incorrect, (too large) also small data will not even show up in the render window as the clipping planes will be wrong. This change " if (cameraParallel == 0 && dot(normalVCVSOutput,vertexVC.xyz) > 0.0) { normalVCVSOutput = -1.0*normalVCVSOutput; }" I did not make and do not know its purpose. I think we need a solution that works for both caves and planar display hardware, and I think the underlying issue is that there is different render code being used, that is a subset of the full normal rendering solution, which is creating these issues. I think the correct solution is to remove the separate render code and use the primary code for both client and server rendering of mono and stereo. I do not have a cave to test with, but I do not see why we can not find a solution that works for everyone. Thanks, Joe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph G. Hennessey Ph.D., SAIC Team SAIC Army Research Lab DOD Supercomputing Resource Center Aberdeen Proving Ground, MD 21005 -----Original Message----- From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Stock, Mark Sent: Friday, June 23, 2017 5:23 PM To: Gena Bug via ParaView <paraview@paraview.org> Subject: [Non-DoD Source] [Paraview] Eye separation has been wrong since Immersive ParaView 5.2 - here's how to fix it All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ---- Hello, If you're an Immersive ParaView user, you may have noticed that 5.x versions don't work as well in your CAVE. Specifically, I've noticed the following differences when compared with ParaView 4.4.0: 1) I can place an object in space properly but it seems to move 10x as fast when I move my head. 2) If I move the object just a little farther away from its initial position, it clips out (vanishes). 3) When I am viewing a triangle mesh, some triangles seem to flip normals (and get dark) when I move the object around. The first two problems are caused by a change in the VTK source code from March 2016 which arbitrarily multiples the eye separation distance by 10, and also tightens the near and far clipping planes. The third can be corrected by adding a single comment (which will help CAVE and Immersive users, but probably nobody else). Both fixes will require you to build ParaView from source - which you're probably doing anyway. I can't comment on how these changes will affect HMD VR users. The first and second problems are caused by a single commit to the VTK repository that began to appear in ParaView with version 5.2.0. The problem code is in VTK/Rendering/Core/vtkCamera.cxx starting at line 452 in versions 5.3 and 5.4. This problem can be fixed by replacing double eyeSeparationCorrectionFactor = 10.0; double shiftDistance = this->EyeSeparation / (2.0 * eyeSeparationCorrectionFactor); if(this->Distance < 1.0) { shiftDistance *= this->Distance; } with simply double shiftDistance = this->EyeSeparation; The second problem (clipping planes) is just a few lines down. I fixed it by replacing // Front (aka near) double F = E[2] - (this->Distance + this->Thickness);//E[2] - 10000.0;//this->ClippingRange[1]; // Back (aka far) double nearDistanceCorrectionFactor = 1000.0; double B = E[2] - (this->Distance / nearDistanceCorrectionFactor);//E[2] - .1;//this->ClippingRange[0]; with // Front (aka near) double F = E[2] - 10000.0;//this->ClippingRange[1]; // Back (aka far) double B = E[2] - .1;//this->ClippingRange[0]; The third problem can be fixed by commenting out this line in VTK/Rendering/OpenGL2/vtkOpenGLPolyDataMapper.cxx (around line 1198 in 5.1, 1416 in 5.2 to 5.4): " if (cameraParallel == 0 && dot(normalVCVSOutput,vertexVC.xyz) > 0.0) { normalVCVSOutput = -1.0*normalVCVSOutput; }" I hope these fixes help some of you out there get your CAVE updated to the latest ParaView. Mark mark.st...@nrel.gov _______________________________________________ Powered by Caution-www.kitware.com Visit other Kitware open-source projects at Caution-http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: Caution-http://paraview.org/Wiki/ParaView Search the list archives at: Caution-http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: Caution-http://public.kitware.com/mailman/listinfo/paraview
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview