Re: [Paraview] OpenGL Vendor
OpenGL is loaded at runtime so what matters is the mostly the system it is running on as opposed to the system it was compiled on (except OSMesa see below). To make it a bit more complicated, if you use GLXforwarding or a similar OpenGL forwarding mechanism then what matters is some combination of the forwarding library on the system PV is running on and the OpenGL hardware of the system you are *displaying* on. This bites people when PV runs fine locally on a system but when they forward their display/remote desktop to another system it fails. Finally when building with OSMesa, as long as the runtime system picks up the OSMesa libs you built, then it really is the version of OSMesa you compiled against that matters. On linux I think a ldd on the PV executable can show which library is being picked up. (should have ogl or opengl, nvidia, mesa etc in the path) but a linux person might know better. On Thu, Jan 25, 2018 at 7:14 PM, Scott, W Alan <wasc...@sandia.gov> wrote: > With a remote server running on a cluster, what does the Help/ About/ > Connection Information/ OpenGL Version string mean? Where is this found? > Isn’t this the version of OpenGL compiled into the pvserver? What is the > name of this library, and any idea how I can find what is being used? > > > > I have a situation where my builds show OpenGL version 3.3 (and can open a > specific dataset), and a user’s shows 2.1 (and he cannot open a specific > dataset). > > > > Thanks all, > > > > Alan > > > > > > W. Alan Scott > > ParaView Support Manager > > > > SAIC > > Sandia National Laboratories, MS 0807 > > Org 9326 - Building 880 A1-K > > (505) 284-0932 FAX (505) 284-5619 > > > > The most exciting phrase to hear in science > > is not "Eureka!" but "That's funny..." -- Isaac Asimov > > - > > > > ___ > 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: > https://paraview.org/mailman/listinfo/paraview > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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: https://paraview.org/mailman/listinfo/paraview
Re: [Paraview] [Non-DoD Source] Re: ParaView + OpenVR (UNCLASSIFIED)
Those flags look reasonable, but last I checked the OpenVR CMake files had some minor issues. I use a small patch file for OpenVR 1.0.10 in the paraview superbuild. The patch file is here https://gitlab.kitware.com/paraview/paraview-superbuild/blob/master/projects/win32/patches/openvr-improve-install.patch I think it mostly fixes install issues and shared library support. On Fri, Jan 19, 2018 at 9:49 AM, Su, Simon M CIV USARMY RDECOM ARL (US) < simon.m.su@mail.mil> wrote: > CLASSIFICATION: UNCLASSIFIED > > Hi Ken, > > I guess that's the price to pay when working with cutting edge technology > :) Thanks for the OpenVR version info. I used the release version of it. > What is your cmake flag for OpenVR? I just used > > cmake ../OpenVR -DCMAKE_INSTALL_PREFIX=/path/to/install/OpenVR > -DCMAKE_BUILD_TYPE=Release > > Any other variable I need to specify? I will try to compile it with OpenVR > version 1.0.10. Thank you > > And Benson, yes the binary version worked ok with our HTC Vive. > > Thanks > -simon > > -Original Message- > From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Ken > Martin > Sent: Friday, January 19, 2018 9:42 AM > To: Benson Muite <benson.mu...@ut.ee> > Cc: ParaView <paraview@paraview.org> > Subject: [Non-DoD Source] Re: [Paraview] ParaView + OpenVR (UNCLASSIFIED) > > 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. > > > > > > > Hi Simon & Benson, > > I would bet steam has changed their API (again :-) and removed that > method. Maybe try downloading/git checkout using the 1.0.10 version of > OpenVR. That is what I last tested with and it should build fine against > that. > > Thanks! > Ken > > On Thu, Jan 18, 2018 at 11:50 PM, Benson Muite <benson.mu...@ut.ee < > Caution-mailto:benson.mu...@ut.ee > > wrote: > > > Hi, > > Does binary release version work for you? (At present only Windows > is available), seem to be a few things to fix on Linux & Mac. > > > Have you tried build using flags similar to binary release version? > Caution-https://blog.kitware.com/taking-paraview-into- > virtual-reality/ < Caution-https://blog.kitware.com/taking-paraview-into- > virtual-reality/ > > > Benson > > On 01/19/2018 01:29 AM, Su, Simon M CIV USARMY RDECOM ARL (US) > wrote: > > > CLASSIFICATION: UNCLASSIFIED > > Hello, > > I am wondering how to build a version of ParaView with > OpenVR plugin? Which version of OpenVR shall I use? I used the OpenVR from > Caution-https://github.com/ValveSoftware/openvr < Caution- > https://github.com/ValveSoftware/openvr > with just basic/minimal cmake > option. I am using the following cmake line for ParaView > > cmake ..\paraview > -DCMAKE_INSTALL_PREFIX=U:\tools\ParaView\ParaView > -DCMAKE_BUILD_TYPE=Release -G Ninja -DPARAVIEW_ENABLE_PYTHON:BOOL=ON > -DBUILD_TESTING:BOOL=OFF -DPARAVIEW_QT_VERSION=5 -DPARAVIEW_USE_MPI:BOOL=ON > -DPARAVIEW_USE_VISITBRIDGE:BOOL=ON -DBOOST_INCLUDEDIR=U:/tools/ > boost/boost-1.65.1/include/boost-1_65_1 > -DBOOST_ROOT=U:/tools/boost/boost-1.65.1 > -DModule_vtkAcceleratorsVTKm:BOOL=ON -DModule_vtkRenderingOpenVR:BOOL=ON > -DPARAVIEW_BUILD_PLUGIN_OpenVR:BOOL=ON > -DOPENVR_INCLUDE_DIR=U:/tools/OpenVR/OpenVR/include > -DOPENVR_LIBRARY=U:/tools/OpenVR/OpenVR/lib/openvr_api64.lib > > I am running into the following error > > C:\Users\one\build\ParaView\b>ninja > [47/14039] Building CXX object VTK\Rendering\OpenVR\ > CMakeFiles\vtkRenderingOpenVR.dir\vtkOpenVRRenderWindow.cxx.obj > FAILED: VTK/Rendering/OpenVR/ > CMakeFiles/vtkRenderingOpenVR.dir/vtkOpenVRRenderWindow.cxx.obj > > C:\PROGRA~2\MIB055~1\2017\COMMUN~1\VC\Tools\MSVC\1412~1.258\bin\Hostx64\x64\cl.exe > /nologo /TP -DMPICH_IGNORE_CXX_SEEK -DVTK_IN_VTK > -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE > -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE > -D_SCL_SECURE_NO_WARNINGS -DvtkRenderingOpenVR_EXPORTS -I. > -IVTK\Rendering\OpenVR > -IC:\Users\one\build\ParaView\paraview\VTK\Rendering\OpenVR > -IVTK\Common\Core -IC:\Users\one\build\ParaView\paraview\VTK\Common\Core > -IVTK\Utilities\KWIML > -IC:\Users\one\build\ParaView\paraview\VTK\Utilities\KWIML > -IVTK\Utilities\KWSys > -IC:\Users\one\build\ParaView\paraview\VTK\Utilities\KWSys > -IVTK\ThirdPart
Re: [Paraview] ParaView + OpenVR (UNCLASSIFIED)
dParty\lz4 >> -IC:\Users\one\build\ParaView\paraview\VTK\ThirdParty\lz4 >> -IVTK\ThirdParty\expat >> -IC:\Users\one\build\ParaView\paraview\VTK\ThirdParty\expat >> -IVTK\Imaging\Sources >> -IC:\Users\one\build\ParaView\paraview\VTK\Imaging\Sources >> -IVTK\Imaging\Core -IC:\Users\one\build\ParaView\paraview\VTK\Imaging\Core >> -IVTK\Interaction\Style >> -IC:\Users\one\build\ParaView\paraview\VTK\Interaction\Style >> -IVTK\Filters\Extraction -IC:\Users\one\build\ParaView\ >> paraview\VTK\Filters\Extraction -IVTK\Filters\Statistics >> -IC:\Users\one\build\ParaView\paraview\VTK\Filters\Statistics >> -IVTK\Imaging\Fourier >> -IC:\Users\one\build\ParaView\paraview\VTK\Imaging\Fourier >> -IVTK\ThirdParty\alglib >> -IC:\Users\one\build\ParaView\paraview\VTK\ThirdParty\alglib >> -IVTK\Rendering\Core >> -IC:\Users\one\build\ParaView\paraview\VTK\Rendering\Core >> -IVTK\Common\Color -IC:\Users\one\build\ParaView\paraview\VTK\Common\Color >> -IVTK\Filters\Geometry >> -IC:\Users\one\build\ParaView\paraview\VTK\Filters\Geometry >> -IVTK\Interaction\Widgets -IC:\Users\one\build\ParaView\ >> paraview\VTK\Interaction\Widgets -IVTK\Filters\Hybrid >> -IC:\Users\one\build\ParaView\paraview\VTK\Filters\Hybrid >> -IVTK\Filters\Modeling >> -IC:\Users\one\build\ParaView\paraview\VTK\Filters\Modeling >> -IVTK\Imaging\Color -IC:\Users\one\build\ParaView\paraview\VTK\Imaging\Color >> -IVTK\Imaging\General >> -IC:\Users\one\build\ParaView\paraview\VTK\Imaging\General >> -IVTK\Imaging\Hybrid >> -IC:\Users\one\build\ParaView\paraview\VTK\Imaging\Hybrid >> -IVTK\Rendering\Annotation -IC:\Users\one\build\ParaView\ >> paraview\VTK\Rendering\Annotation -IVTK\Rendering\FreeType >> -IC:\Users\one\build\ParaView\paraview\VTK\Rendering\FreeType >> -IVTK\ThirdParty\freetype -IC:\Users\one\build\ParaView\ >> paraview\VTK\ThirdParty\freetype -IVTK\Rendering\Volume >> -IC:\Users\one\build\ParaView\paraview\VTK\Rendering\Volume -IVTK\IO\XML >> -IC:\Users\one\build\ParaView\paraview\VTK\IO\XML >> -IVTK\Rendering\OpenGL2 >> -IC:\Users\one\build\ParaView\paraview\VTK\Rendering\OpenGL2 >> -IVTK\ThirdParty\glew >> -IC:\Users\one\build\ParaView\paraview\VTK\ThirdParty\glew >> -IVTK\Rendering\VolumeOpenGL2 -IC:\Users\one\build\ParaView\ >> paraview\VTK\Rendering\VolumeOpenGL2 -IVTK\Imaging\Math >> -IC:\Users\one\build\ParaView\paraview\VTK\Imaging\Math >> -IU:\tools\OpenVR\OpenVR\include -IVTK\Utilities\KWSys\vtksys /DWIN32 >> /D_WINDOWS /W4 /GR /EHsc /MD /O2 /Ob2 /DNDEBUG /showIncludes >> /FoVTK\Rendering\OpenVR\CMakeFiles\vtkRenderingOpenVR.dir\vtkOpenVRRenderWindow.cxx.obj >> /FdVTK\Rendering\OpenVR\CMakeFiles\vtkRenderingOpenVR.dir\ /FS -c >> C:\Users\one\build\ParaView\paraview\VTK\Rendering\OpenVR\vt >> kOpenVRRenderWindow.cxx >> C:\Users\one\build\ParaView\paraview\VTK\Rendering\OpenVR\vtkOpenVRRenderWindow.cxx(281): >> error C2039: 'IsInputFocusCapturedByAnotherProcess': is not a member of >> 'vr::IVRSystem' >> U:\tools\OpenVR\OpenVR\include\openvr.h(1375): note: see declaration of >> 'vr::IVRSystem' >> [56/14039] Building CXX object VTK\Wrapping\Python\CMakeFi... >> tkCommonCorePythonD.dir\vtkConditionVariablePython.cxx.obj >> ninja: build stopped: subcommand failed. >> >> >> Any help is much appreciated. >> >> Thanks >> -simon >> >> >> CLASSIFICATION: UNCLASSIFIED >> ___________ >> 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: >> https://paraview.org/mailman/listinfo/paraview >> >> > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/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: > https://paraview.org/mailman/listinfo/paraview > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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: https://paraview.org/mailman/listinfo/paraview
[Paraview] Windows Mixed Reality
Just a FYI, I just had a chance to test out a new Windows Mixed Reality headset and it seems to work well with VTK and ParaView through the SteamVR driver. I was testing the new Dell Visor headset and controller. The controllers show up properly and the controls map to reasonable settings. Tracking was surprisingly good. -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Python in the VR Build
I believe the nightly PV builds now include the OpenVR plugin on windows. I have not had a chance to try it but it might do the trick. On Sat, Dec 2, 2017 at 5:07 PM, Bane Sullivan <banesu...@gmail.com> wrote: > Is it possible to release a Python compatible version of the VR build of > ParaView? > > I am working on a project where I am dynamically linking geophysical > processing code to ParaView for near-real time visualizations. Having > Python included in the VR build would be a huge benefit! > > This would also help me for the static visualizations I am working with > where I have created tons of file readers and filters in the Python > Programmable Filter/Source format. Checkout my project here: > https://github.com/banesullivan/ParaViewGeophysics > > Thanks, > > B > > > ___ > 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 > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Fwd: OpenGL version
All versions of paraview should work with OpenGL 4.1 so that error message is really odd. Given that updating the driver fixes the issue, it could be a driver bug. How old is the driver that is working with your other monitor? On Wed, Nov 22, 2017 at 1:49 PM, Devang Chauhan <dev...@gmail.com> wrote: > Hi All, > > Can someone please recommend me version of Paraview that can work with > OpenGL version 4.1.0? In order to address this myself, I have been > downloading and testing older versions. I went down to paraview version > 5.0. > > Updating the graphic driver is one of the solutions and it works but doing > that unfortunately creates issues with two monitors I attach to my laptop > PC. So I would like to stick with this OpenGL version please. > > If somebody can help me identify the compatible version that would be a > great help. I also attached the error I receive when I start paraview. > > - Devang > > > ___ > 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 > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] OpenGL inside VMWare virtual machine
This could be a PV Qt interaction. Try setting MESA_GL_VERSION_OVERRIDE=3.2
in your environment
Basically there is a bug in Qt on windows where it refuses to see the 3.2
context from Mesa because it is not a compatibility context.
On Wed, Nov 15, 2017 at 10:09 AM, Cornelis Bockemühl <
cornelis.bockemu...@gmail.com> wrote:
> Dear all,
>
> I know that I cannot go for any performance record with this setup, but
> having both systems available without reboot has advantages if it is about
> testing some new development. WOULD have - if it fully worked! So far it
> looks like I am "almost there" - however not knowing whether the last 10
> meters will be feasible at all...
>
> This is my setup:
>
> Main system: Opensuse Linux "Leap" 42.3, with Paraview reporting the
> following in the About dialog:
> OpenGL Vendor: Intel Open Source Technology Center
> OpenGL Version: 3.3 (Core Profile) Mesa 17.0.5
> OpenGL Renderer: Mesa DRI Intel(R) Ivybridge Mobile
>
> On this system Paraview (latest version, self compiled) runs just fine.
>
> Guest system inside VMWare Player version 14: Windows 10, with Paraview
> reporting the following:
> OpenGL Vendor: VMware, Inc.
> OpenGL Version: 3.3 (Core Profile) Mesa 11.2.0 (git-b9d3786)
> OpenGL Renderer: Gallium 0.4 on SVGA3D; build: RELEASE; LLVM;
>
> Here Paraview immediately complains on startup, reporting the following in
> the message output dialog: see below.
>
> For me the version numbers look ok (OpenGL 3.3 is more than 3.2, and Mesa
> 11.2.0 is more than 10.6.5), but there is some "fineprint" about shader
> capabilities that are going a bit above my understanding...
>
> Anybody able to help with this?
>
> Any possibility to "cheat" somehow? Note that I am certainly not going to
> render billions of data in this configuration!
>
> Or should I abandon this tricky setup altogether?
>
> Thanks and regards,
> Cornelis
>
> Here the error output from the Windows Paraview inside the VMWare virtual
> machine:
>
> ERROR: In Z:\ultrabay\ParaView\Sources\ParaView-v5.4.1\VTK\Rendering\
> OpenGL2\vtkOpenGLRenderWindow.cxx, line 831
> vtkGenericOpenGLRenderWindow (02438C350630): GL version 2.1 with the
> gpu_shader4 extension is not supported by your graphics driver but is
> required for the new OpenGL rendering backend. Please update your OpenGL
> driver. If you are using Mesa please make sure you have version 10.6.5 or
> later and make sure your driver in Mesa supports OpenGL 3.2.
>
> ERROR: In
> Z:\ultrabay\ParaView\Sources\ParaView-v5.4.1\VTK\Rendering\OpenGL2\vtkShaderProgram.cxx,
> line 408
> vtkShaderProgram (02438C1B80C0): 1: #version 150
> 2: #ifdef GL_ES
> 3: #if __VERSION__ == 300
> 4: #define attribute in
> 5: #define varying out
> 6: #endif // 300
> 7: #else // GL_ES
> 8: #define highp
> 9: #define mediump
> 10: #define lowp
> 11: #if __VERSION__ == 150
> 12: #define attribute in
> 13: #define varying out
> 14: #endif
> 15: #endif // GL_ES
> 16:
> 17:
> 18: /*==
> ===
> 19:
> 20: Program: Visualization Toolkit
> 21: Module:vtkPolyDataVS.glsl
> 22:
> 23: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen
> 24: All rights reserved.
> 25: See Copyright.txt or http://www.kitware.com/Copyright.htm for
> details.
> 26:
> 27: This software is distributed WITHOUT ANY WARRANTY; without even
> 28: the implied warranty of MERCHANTABILITY or FITNESS FOR A
> PARTICULAR
> 29: PURPOSE. See the above copyright notice for more information.
> 30:
> 31:
> =*/
> 32:
> 33: attribute vec4 vertexMC;
> 34:
> 35: // frag position in VC
> 36: //VTK::PositionVC::Dec
> 37:
> 38: // optional normal declaration
> 39: //VTK::Normal::Dec
> 40:
> 41: // extra lighting parameters
> 42: //VTK::Light::Dec
> 43:
> 44: // Texture coordinates
> 45: //VTK::TCoord::Dec
> 46:
> 47: // material property values
> 48: //VTK::Color::Dec
> 49:
> 50: // clipping plane vars
> 51: //VTK::Clip::Dec
> 52:
> 53: // camera and actor matrix values
> 54: uniform mat4 MCDCMatrix;
> 55:
> 56: // Apple Bug
> 57: //VTK::PrimID::Dec
> 58:
> 59: // Value raster
> 60: //VTK::ValuePass::Dec
> 61:
> 62: void main()
> 63: {
> 64: //VTK::Color::Impl
> 65:
> 66: //VTK::Normal::Impl
> 67:
> 68: //VTK::TCoord::Impl
> 69:
> 70: //VTK::Clip::Impl
> 71:
> 72: //VTK::PrimID::Impl
> 73:
> 74: gl_Position = MCDCMatrix * vertexMC;
> 75:
> 76:
> 77: //VTK::ValuePass::Impl
> 78:
> 79: //VTK
Re: [Paraview] ParaView VR - issue with new steam vr
We have fixed the issue and it has been merged into VTK master. Likewise the PV executable download for OpenVR has been updated as well. Thanks! Ken On Thu, Oct 19, 2017 at 2:19 PM, Ken Martin <ken.mar...@kitware.com> wrote: > > Be aware if you are using the ParaView VR version with OpenVR support that > a recent driver update from steam has introduced some issues causing events > to be processed with delays. We should have a fixed version up in a week or > so. > > Thanks > Ken > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
[Paraview] ParaView VR - issue with new steam vr
Be aware if you are using the ParaView VR version with OpenVR support that a recent driver update from steam has introduced some issues causing events to be processed with delays. We should have a fixed version up in a week or so. Thanks Ken -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Implementation of OpenGL 4
VTK OpenGL2 uses automatic data normalization (shift/scaling) to handle large data ranges. So each mapper's data is rescaled/shifted to lie within the 0.0 to 1.0 range and the camera matrix is modified to account for this. All that is done in double precision but resulting in floating point data and matrix. For most earth centric data sets the normalization works well if your detailed data (like of a building) is in a different mapper than your large scale data (model of the earth). I am not sure if this functionality is in the last PV release, but it should be in the nightly version. There are still some gotchas in setting the camera's clipping range (an automatic clipping range that includes the entire earth will be really bad for a detailed model of a building) but the basic support is there. In terms of adding double support it could be done conditionally if the hardware has it then turn it on. We already do that for a couple OpenGL 3.3 features. But I doubt we will require OpenGL 4 any time soon as moving to OpenGL 3.2 was a stretch for many people. Having said that, we do typically get OpenGL 4 contexts on many platforms by default. Hope some of that helps! Ken On Tue, Oct 10, 2017 at 1:56 AM, Lieberwirth, Undine < undine.lieberwi...@fu-berlin.de> wrote: > Hello list, > > I am using real (long - more than 7 digits) geographic coordinates in my > project. Unfortunately, with OpenGL 2 they cannot be visualised in > ParaView. I am therefore in need of the implementation of OpenGL 4 (or > higher) in ParaView. Is there already an ongoing project or can we join a > team which is already working on this subject? > Kind regards > Undine > > > > > > > Undine Lieberwirth M.A. > Freie Universität Berlin > Exzellenzcluster Topoi 264 > Forum Spatial Data > Hittorfstr. 18 > 14195 Berlin > Tel. +49 30 838 57275 <+49%2030%2083857275> > Fax +49 838 53770 <+49%208385%203770> > Email: undine.lieberwi...@fu-berlin.de > Websites: topoi.org, community.topoi.org/web/forum-sda > > > > > > > > > ___ > 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 > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
[Paraview] Updated OpenVR/Vive support
A quick update on some improved support for OpenVR/Vive in ParaView. Over the past few months there has been a lot of work put into improving the integration of OpenVR with ParaView and VTK including extending VTK's event model to better handle 3D events. Almost all of these changes have been merged to VTK and PV master now for you to enjoy. They are still in development so you may run into issues crashes etc. Here are some of the new features - OpenVR support is now a plugin that can loaded into PV like any other plugin. It does require PV be built with the vtkRenderingOpenVR modules though. - The ParaView GUI no longer locks up when in VR this allows animations etc to be run while in VR (alpha, send to VR first then start the animation) - It now supports selection of scalar field while in VR - It now supports adding multiple crop widgets in VR - It no longer depends on the SDL2 library - It now supports the distance widget in VR - It now support cell data probing from within VR - It supports navigation panel in VR showing location and bearing - It loads/saves recorded camera poses into the PV state file - Includes a new Menu Widget that provides an easy API for adding menus and submenus into VR. - Includes optional floating labels for controller buttons These changes reflect a lot of work from Lucas Gandel, Jc Fillion-Robin and Jean-Baptiste Vimort as well as generous support from our commercial and federal customers. You can find a windows executable at the paraview download page and a direct link here https://www.paraview.org/paraview-downloads/download.php?submit=Download=v5.4=binary=Windows=ParaView-OpenVR-Windows-64bit.zip And over the next few weeks we hope to get a nightly release with Python started that includes OpenVR support as well. Please let me know if you run into issues, have contributions, or would like to talk about future work/extensions. Thanks! Ken -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Uncomplete display of large unstructured grid
If possible can you try updating the Intel driver for your HD4000 and see if that makes a difference? https://downloadcenter.intel.com/product/81499/Intel-HD-Graphics-4000 On Fri, Aug 25, 2017 at 11:11 PM, Cornelis Bockemühl < cornelis.bockemu...@gmail.com> wrote: > Hello all, > > With some self-written plugin I am generating rather large "unstructured > grids". With a model with something more than 700'000 blocks I realized > that on my Lenovo notebook I did not get a complete display of all the > blocks, so I made tests with subsets of the data. It turns out that with > less than 1000 blocks everything works fine, with 20'000 blocks there are > already some "reductions" and finally with the full model even more: see > the attached Powerpoint with screenshots (plus details about my system and > the Paraview version). > > My question is now if there is possibly some kind of "graphic card > overflow" happening? I could so far not test the software with the same > model on another computer. > > And whatever the reason is: is there something that I can do about it? > > It is to say that the unstructured grid is a bit "unconventional" by the > fact that often adjacent blocks do not have common edges and points, > sharing thus only common partial faces. With this one possibility would be > that Paraview cannot properly carry out certain optimizations that are > relying on the fact that neighbor blocks "normally" (??) share a face, > edges and points. However I do not know whether this is an issue or not!? > In this case it might be an option to change the entire data set to a set > of just cubes that happen to touch each other. > > Regards, Cornelis > > -- > Cornelis Bockemühl > Basel, Schweiz > > ___ > 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 > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] [EXTERNAL] Black box when starting parvaview
I have seen this with ParaView 5.4 on one of my 3-4 year old laptops. I have to turn off the nvidia chip so I am using the Intel GPU to see the issue. For me it impacts all rendering, not just volumes as some have reported. As soon as I startup PV 5.4 I get the black box in the corner where the axis actor is positioned. I just realized Cory and Utkarsh are both on vacation which is probably why this issue has been a bit quite on the Kitware side. On Thu, Jun 15, 2017 at 12:05 PM, Scott, W Alan <wasc...@sandia.gov> wrote: > Has anyone at Kitware seen this issue? > > > > On a Windows box, just open ParaView. There will be a black window lower > left side of the 3d view. > > > > Alan > > > > > > *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of *Josué > Aristide Paul Barboza > *Sent:* Thursday, June 15, 2017 7:33 AM > *To:* Ken Martin <ken.mar...@kitware.com> > *Cc:* Geoffrey Garner <xov...@tamu.edu>; paraview@paraview.org > *Subject:* Re: [Paraview] [EXTERNAL] Black box when starting parvaview > > > > Disabling the FXAA antialiasing on 3D geometry ( Menu > Edit->Settings->Render View->disable "Use FXAA" ) has fixed my "black box" > issue. > > > > Regards, > > > > 2017-06-15 14:54 GMT+02:00 Ken Martin <ken.mar...@kitware.com>: > > For others that have the same issue, was the solution using 5.3 or > building against Qt4 for you? > > > > On Wed, Jun 14, 2017 at 4:08 PM, Geoffrey Garner <xov...@tamu.edu> wrote: > > That seemed to solve the issue. > > > > *From: *Ken Martin <ken.mar...@kitware.com> > *Sent: *Wednesday, June 14, 2017 2:46 PM > *To: *Scott, W Alan <wasc...@sandia.gov> > *Cc: *Geoffrey Garner <xov...@tamu.edu>; paraview@paraview.org > *Subject: *Re: [Paraview] [EXTERNAL] Black box when starting parvaview > > > > I have seen this on one of my intel GPU systems as well. I think it is a > known issue we are having with the new Qt version and those systems > specific to Windows. I would bet the prior version of ParaView (5.3?) will > work. Probably if you built the 5.4 version of ParaView against Qt4 it > would work as well. > > > > - Ken > > > > > > > > > > > > On Wed, Jun 14, 2017 at 1:45 PM, Scott, W Alan <wasc...@sandia.gov> wrote: > > Only thing I can think of is to blow away your configuration files. These > do persist between versions, and I have seen these go bad. > https://www.paraview.org/Wiki/ParaView_Settings_Files > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.paraview.org_Wiki_ParaView-5FSettings-5FFiles=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=iBhjvw5NB_7coV9ytrmJ0EfBdyuoRLtIjwBdszLz2Ak=> > . > > > > Alan > > > > *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of > *Geoffrey > Garner > *Sent:* Wednesday, June 14, 2017 11:26 AM > *To:* paraview@paraview.org > *Subject:* [EXTERNAL] [Paraview] Black box when starting parvaview > > > > When I open Paraview 5.4.0 amd64 win10, I see the following black box on > the screen. The box was not originally there and expands to the entire > screen when data is loaded. Because the coordinate arrows should be there, > I believe this has something to do with rendering. I have tried > uninstalling and reinstalling the software, to no avail. Has anyone got any > ideas? > > > > > > > > Thanks. > > > > > ___ > Powered by www.kitware.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=7HJmIG0AwNgHFRL3cWld_9fyw0c1anh1KrTRnQGmoT8=> > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=LNAakNfDj-yT6K-bd6cearxLyeR_3O-X4t89QNsHxxY=> > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > <https://urldefense.proofpoint.com/v2/url?u=http-3A__paraview.org_Wiki_ParaView=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=HMVc2T8i7iz1zkL1Yd4zXpy6mwn_--nVm4ryVbum468=> > > Search the list archives at: http://markmail.org/search/?q=ParaView > <https://urldefense.proofpoint.com/v2/url?u=http-3A__markmail.org_search_-3Fq-3DParaView=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVV
Re: [Paraview] [EXTERNAL] Black box when starting parvaview
I believe for RDP in some cases you can get it to work by starting the application before you connect with RDP. That way it gets a real OpenGL implementation. There are some threads on the internet about using time delayed scripts to do this etc. e.g. connect with RDP, run a script to launch the application in two minutes. Disconnect. Two minutes later reconnect and there is your app running with a real OpenGL. Why Microsoft makes this so difficult is a mystery to me. Probably because they originally wanted to forward the OpenGL calls as opposed to the resulting image. If you are connected with RDP Microsoft replaces whatever OpenGL you have with some ancient version of OpenGL and you are stuck back in 1990. I believe Nomachine and VNC both work as alternatives if you have that option. On Fri, Jun 16, 2017 at 3:39 AM, Andrew <antech...@gmail.com> wrote: > Hello. I use ParaView via RDP on remote Windows-7 (x64) machine. Version > 5.4.0 (x64) shows black render window... > Disabling FXAA didn't help. Some info from About dialog: Qt version: > 5.8.0, OpenGL Vendor: NVIDIA Corporation, OpenGL Version: 4.5.0 NVIDIA > 377.35 (current driver version is installed), OpenGL renderer: Quadro > K4000/PCIe/SSE2. Vesrions up to 5.2 work good. I understand that it's > likely an RDP issue and don't hope that newer versions will work so just > use 5.2 on this machine. > > 2017-06-15 19:05 GMT+03:00 Scott, W Alan <wasc...@sandia.gov>: > >> Has anyone at Kitware seen this issue? >> >> >> >> On a Windows box, just open ParaView. There will be a black window lower >> left side of the 3d view. >> >> >> >> Alan >> >> >> >> >> >> *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of *Josué >> Aristide Paul Barboza >> *Sent:* Thursday, June 15, 2017 7:33 AM >> *To:* Ken Martin <ken.mar...@kitware.com> >> *Cc:* Geoffrey Garner <xov...@tamu.edu>; paraview@paraview.org >> *Subject:* Re: [Paraview] [EXTERNAL] Black box when starting parvaview >> >> >> >> Disabling the FXAA antialiasing on 3D geometry ( Menu >> Edit->Settings->Render View->disable "Use FXAA" ) has fixed my "black box" >> issue. >> >> >> >> Regards, >> >> >> >> 2017-06-15 14:54 GMT+02:00 Ken Martin <ken.mar...@kitware.com>: >> >> For others that have the same issue, was the solution using 5.3 or >> building against Qt4 for you? >> >> >> >> On Wed, Jun 14, 2017 at 4:08 PM, Geoffrey Garner <xov...@tamu.edu> wrote: >> >> That seemed to solve the issue. >> >> >> >> *From: *Ken Martin <ken.mar...@kitware.com> >> *Sent: *Wednesday, June 14, 2017 2:46 PM >> *To: *Scott, W Alan <wasc...@sandia.gov> >> *Cc: *Geoffrey Garner <xov...@tamu.edu>; paraview@paraview.org >> *Subject: *Re: [Paraview] [EXTERNAL] Black box when starting parvaview >> >> >> >> I have seen this on one of my intel GPU systems as well. I think it is a >> known issue we are having with the new Qt version and those systems >> specific to Windows. I would bet the prior version of ParaView (5.3?) will >> work. Probably if you built the 5.4 version of ParaView against Qt4 it >> would work as well. >> >> >> >> - Ken >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jun 14, 2017 at 1:45 PM, Scott, W Alan <wasc...@sandia.gov> >> wrote: >> >> Only thing I can think of is to blow away your configuration files. >> These do persist between versions, and I have seen these go bad. >> https://www.paraview.org/Wiki/ParaView_Settings_Files >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.paraview.org_Wiki_ParaView-5FSettings-5FFiles=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=iBhjvw5NB_7coV9ytrmJ0EfBdyuoRLtIjwBdszLz2Ak=> >> . >> >> >> >> Alan >> >> >> >> *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of >> *Geoffrey >> Garner >> *Sent:* Wednesday, June 14, 2017 11:26 AM >> *To:* paraview@paraview.org >> *Subject:* [EXTERNAL] [Paraview] Black box when starting parvaview >> >> >> >> When I open Paraview 5.4.0 amd64 win10, I see the following black box on >> the screen. The box was not originally there and expands to the entire >> screen when data is loaded. Because the coordinate arrows should be there, >> I believe this has something to do with rendering. I have tried >> uni
Re: [Paraview] [EXTERNAL] Black box when starting parvaview
For others that have the same issue, was the solution using 5.3 or building against Qt4 for you? On Wed, Jun 14, 2017 at 4:08 PM, Geoffrey Garner <xov...@tamu.edu> wrote: > That seemed to solve the issue. > > > > *From: *Ken Martin <ken.mar...@kitware.com> > *Sent: *Wednesday, June 14, 2017 2:46 PM > *To: *Scott, W Alan <wasc...@sandia.gov> > *Cc: *Geoffrey Garner <xov...@tamu.edu>; paraview@paraview.org > *Subject: *Re: [Paraview] [EXTERNAL] Black box when starting parvaview > > > > I have seen this on one of my intel GPU systems as well. I think it is a > known issue we are having with the new Qt version and those systems > specific to Windows. I would bet the prior version of ParaView (5.3?) will > work. Probably if you built the 5.4 version of ParaView against Qt4 it > would work as well. > > > > - Ken > > > > > > > > > > > > On Wed, Jun 14, 2017 at 1:45 PM, Scott, W Alan <wasc...@sandia.gov> wrote: > > Only thing I can think of is to blow away your configuration files. These > do persist between versions, and I have seen these go bad. > https://www.paraview.org/Wiki/ParaView_Settings_Files > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.paraview.org_Wiki_ParaView-5FSettings-5FFiles=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=iBhjvw5NB_7coV9ytrmJ0EfBdyuoRLtIjwBdszLz2Ak=> > . > > > > Alan > > > > *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of > *Geoffrey > Garner > *Sent:* Wednesday, June 14, 2017 11:26 AM > *To:* paraview@paraview.org > *Subject:* [EXTERNAL] [Paraview] Black box when starting parvaview > > > > When I open Paraview 5.4.0 amd64 win10, I see the following black box on > the screen. The box was not originally there and expands to the entire > screen when data is loaded. Because the coordinate arrows should be there, > I believe this has something to do with rendering. I have tried > uninstalling and reinstalling the software, to no avail. Has anyone got any > ideas? > > > > > > [image: cid:image001.png@01D2E503.AA268740] > > > > Thanks. > > > > > ___ > Powered by www.kitware.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=7HJmIG0AwNgHFRL3cWld_9fyw0c1anh1KrTRnQGmoT8=> > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=LNAakNfDj-yT6K-bd6cearxLyeR_3O-X4t89QNsHxxY=> > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > <https://urldefense.proofpoint.com/v2/url?u=http-3A__paraview.org_Wiki_ParaView=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=HMVc2T8i7iz1zkL1Yd4zXpy6mwn_--nVm4ryVbum468=> > > Search the list archives at: http://markmail.org/search/?q=ParaView > <https://urldefense.proofpoint.com/v2/url?u=http-3A__markmail.org_search_-3Fq-3DParaView=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=JdwlhRmiogzBLXS8aHi0CFTOjoz94Ik4aYi1x3_n8ig=> > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/paraview > <https://urldefense.proofpoint.com/v2/url?u=http-3A__public.kitware.com_mailman_listinfo_paraview=DwMFaQ=ODFT-G5SujMiGrKuoJJjVg=YadgenwRslNFl9DVVSjeQg=7W5i_TtkCm0BvxW_gg2fvJHH0m2dZnolnNjj59NeFls=4fFtel4NJ9bgfAk7sUxcTb2BhDA7Vix3XESmBaG_PG0=> > > > > > > -- > > Ken Martin PhD > > Distinguished Engineer > Kitware Inc. > > 28 Corporate Drive > Clifton Park NY 12065 > > > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the
Re: [Paraview] [EXTERNAL] Black box when starting parvaview
I have seen this on one of my intel GPU systems as well. I think it is a known issue we are having with the new Qt version and those systems specific to Windows. I would bet the prior version of ParaView (5.3?) will work. Probably if you built the 5.4 version of ParaView against Qt4 it would work as well. - Ken On Wed, Jun 14, 2017 at 1:45 PM, Scott, W Alan <wasc...@sandia.gov> wrote: > Only thing I can think of is to blow away your configuration files. These > do persist between versions, and I have seen these go bad. > https://www.paraview.org/Wiki/ParaView_Settings_Files. > > > > Alan > > > > *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of > *Geoffrey > Garner > *Sent:* Wednesday, June 14, 2017 11:26 AM > *To:* paraview@paraview.org > *Subject:* [EXTERNAL] [Paraview] Black box when starting parvaview > > > > When I open Paraview 5.4.0 amd64 win10, I see the following black box on > the screen. The box was not originally there and expands to the entire > screen when data is loaded. Because the coordinate arrows should be there, > I believe this has something to do with rendering. I have tried > uninstalling and reinstalling the software, to no avail. Has anyone got any > ideas? > > > > > > > > Thanks. > > > > ___ > 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 > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] ParaView v5.3: Generating textures from scalars and lookup table
Awesome, glad it worked out! On Sun, May 7, 2017 at 8:32 AM, Nenad Vujicic <nena...@gmail.com> wrote: > > >> >* Does anyone have idea how to solve generating textures problem? > *> >> >* I continued to decompose the problem and I'm curious, is > interpolation of > *> >* scalars before mapping performed (when OpenGL2 is selected) by shaders > *> >* (on-the-fly, during display) or is an intermediate texture generated? > *> > > > 2xN is a good texture. That is what you should get for both the old and new > > backends (N covers the scalar range, the 2 covers normal versus NaN, it is > > a 2D map because of how normal scalar values should properly interpolate to > > NaN). > > > ... > > Ken, thank you very much for your help. I think I solved my problem of > simulating InterpolateScalarsBeforeMapping (and getting sharp edges) by > re-creating larger colormap (4x1K) from generated one. > > Thanks very much once again to everyone for helping! > > > Nenad. > > > > ___ > 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 > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] ParaView v5.3: Generating textures from scalars and lookup table
> > Does anyone have idea how to solve generating textures problem? > > I continued to decompose the problem and I'm curious, is interpolation of > scalars before mapping performed (when OpenGL2 is selected) by shaders > (on-the-fly, during display) or is an intermediate texture generated? > 2xN is a good texture. That is what you should get for both the old and new backends (N covers the scalar range, the 2 covers normal versus NaN, it is a 2D map because of how normal scalar values should properly interpolate to NaN). When interp before mapping is on we do create a 2xN texture and texture coordinates. The texture coordinate maps the scalar values into the texture map. Interpolation is done in the fragment shader by texture lookup. The process for cell data is a bit different but in that case there is no interpolation. There we use a texture to map cellids to colors I believe. If you have point scalars, and you write out the 2xN texture map along with the color texture coordinates generated for it (not the texture coordinates that might have come from the model or a source), then that should be correct. Also, in OpenGL case, vtkPainter was available. This is missing in OpenGL2. > Where has this functionality moved to or is it missing? > OpenGL2 has a different design that does not use painters. > > Nenad. > > On Tue, Apr 25, 2017 at 11:59 AM, Nenad Vujicic <nena...@gmail.com> wrote: > >> David, >> >> Thank you very much for your response! I tried what you suggested and it >> worked, but, I'm getting bad texture, i.e. I get texture 2xN, where N is >> number of segments in colormap and the exported texture mapped object looks >> like I turned OFF InterpolateScalarsBeforeMapping flag. I would like to >> simulate InterpolateScalarsBeforeMapping behavior by baking entire >> texture first and exporting it. You can easily see difference if you create >> Wavelet source, turn ON Surface representation, select RTData array for >> coloring and set Number Of Table Values (in Color Map Editor) to e.g. 5. >> >> What I did in background is: I patched vtkCompositePolyDataMapper2Internal >> and vtkCompositePolyDataMapper2, so I'm able to access appropriate block >> mapper and get rid of old colormap texture, coordinates, colors, call >> MapScalars(), dump created ColorMapTexture to .vti file (everything >> performed on block-mapper). >> >> Do you have some idea where I made mistake? >> >> Thanks in advance! >> >> Nenad. >> >> >> On Thu, Apr 13, 2017 at 2:33 PM, David E DeMarle < >> dave.dema...@kitware.com> wrote: >> >>> Hi Nenand, >>> >>> You might try vtkMapper::GetColorMapColors/C >>> olorCoordinates/ColorTextureMap. I'm using this in the OSPRay renderer >>> for example. >>> >>> Out of curiosity is this for the p2f3d exporter plugin? >>> >>> cheers >>> >>> >>> David E DeMarle >>> Kitware, Inc. >>> R Engineer >>> 21 Corporate Drive >>> Clifton Park, NY 12065-8662 >>> Phone: 518-881-4909 <(518)%20881-4909> >>> >>> On Tue, Apr 11, 2017 at 6:34 AM, Nenad Vujicic <nena...@gmail.com> >>> wrote: >>> >>>> Hello everyone, >>>> >>>> I've just started building my ParaView exporter plugin using ParaView >>>> v5.3 with OpenGL2 selected for backend rendering >>>> (PARAVIEW_RENDERING_BACKEND), however, I'm having troubles with generating >>>> textures from scalars used for coloring the meshes. What I'm actually doing >>>> here is that I'm generating texture from currently selected array and >>>> lookup-table and I export texture mapped object instead of exporting object >>>> plus scalars and colormap or colors. Previously (with OpenGL used for >>>> backend rendering), I was deriving class from vtkScalarsToColorsPainter >>>> class for this purpose, however, now, this class is not used anymore with >>>> OpenGL2. >>>> >>>> Does anyone have idea how to solve this problem? >>>> >>>> Thanks in advance, >>>> Nenad. >>>> >>>> ___ >>>> 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=
Re: [Paraview] [vtkusers] VTK files in Virtual Reality
If you are talking about ParaView to VR (OpenVR) then you can view as many VTK files as you want at once. Just open them up in ParaView and then send to VR. The animation panel currently is not supported, so no animations from ParaView to VR. On Tue, May 2, 2017 at 1:59 PM, Aashish Chaudhary < aashish.chaudh...@kitware.com> wrote: > Justin you may want to send this to vtk mailing list in the future. > > I believe you are asking for HMD VR as opposed to Cave VR? If the answer > is 1) you can look at the sample application in the VTK source code and add > multiple models as you needed. Can you provide more detail on what you are > trying to do? > > Thanks, > > > On Tue, May 2, 2017 at 1:06 PM Justin McGinnity <mcginni...@tamu.edu> > wrote: > >> Howdy, >> >> I have a question concerning visualizing VTK files in Virtual Reality. >> Currently it seems that only one VTK file can be viewed at a time in >> Virtual Reality. Will it be possible in the future to loop through VTK >> files in Virtual Reality as is possible in the Render View? Or is this >> already implemented but requires a settings change? >> >> >> *Sincerely,* >> >> Justin McGinnity >> Texas A University *- *Class of 2019 >> Mechanical Engineering Major *&& *Computer Science Minor >> mcginni...@tamu.edu* ||* 909.740.5442 <(909)%20740-5442> >> ___ >> 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 >> > > ___ > 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 VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Compiling Paraview 5.2 GCC 4.8 vtkOpenGLRenderWindow.cxx, line 641
You need OpenGL version 3.2, try updating mesa to version 12 or later. (11.2 should work also if you are not using OSMesa) Thanks Ken On Tue, Feb 21, 2017 at 8:39 AM, Nabil Ghodbane <nabil.ghodb...@gmail.com> wrote: > dear experts, > I am trying to compile Paraview 5.2 with gcc 4.8 + Qt 4.8 + VTK 5.10 + > Python 2.7 (available with Miniconda) on a CentOS 7 machine. > > it compiles well, but I fail to run the Paraview; Paraview starts, but > when I try to open a file, I get: > > ERROR: In > /root/ParaView-v5.2.0/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, > line 641 > vtkXOpenGLRenderWindow (0x1b85d60): GL version 2.1 with the gpu_shader4 > extension is not supported by your graphics driver but is required for the > new OpenGL rendering backend. Please update your OpenGL driver. If you are > using Mesa please make sure you have version 10.6.5 or later and make sure > your driver in Mesa supports OpenGL 3.2. > > could some expert either point me to some standard approach, I need to > use, or point me to the relevant cmake flags to set? > thanks for your valuable help > > > Nabil Ghodbane (Ph. D. Habil*.*) > Phone: +33 6 34 42 33 43 <+33%206%2034%2042%2033%2043> > Mailto: nabil.ghodb...@gmail.com > > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] polygon rendered incorrectly
Convex or concave? If concave you need to triangle filter first. More generally, if you have unknown polygons that could be convex, you need to triangle filter first. Just guessing that is the issue. Ken On Sun, Feb 19, 2017 at 11:26 AM, Martin Rose <mros...@gmx.de> wrote: > Greetings, > > I have generated a simple vtk file that contains a single polygon. The > file is shown below. > > # vtk DataFile Version 2.0 > Output > ASCII > DATASET UNSTRUCTURED_GRID > POINTS 6 float > 0.0048265 0.00753943 0 > 0.0048265 0.00752686 0 > 0.00485421 0.00752571 0 > 0.00485266 0.00750789 0 > 0.00485804 0.00750789 0 > 0.00485804 0.00753943 0 > CELLS 1 7 > 6 0 1 2 3 4 5 > CELL_TYPES 1 > 7 > #end of file > > > After loading the file in paraview, the surface of the polygon is not > displayed correctly. It seems that an additional triangle is displayed. > However, the wireframe is displayed correctly. I have checked the order of > points and confirmed that the order is correct. I also multiplied the > coordinates by 100 but the problem persists. > > If I add the first point of the polygon again, the surface is displayed > correctly. The modified lines read: > CELLS 1 8 > 7 0 1 2 3 4 5 0 > > Unfortunately, that fix does not work for other polygons that show the > same problem. > Is there something wrong with my vtk file? > > Greetings, > Martin > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/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 > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Object rendering problem on Windows 7 with Paraview 5.2
That card should be fine. I have seen this type of bug before and updating the driver has fixed it. Specifically updating the driver to the latest from ATI (sometimes computer vendors stop updating their copies). Another way to check what the problem is, is to stick a polydata normals filter in the pipeline and then see if it works. Thanks Ken On Mon, Feb 13, 2017 at 11:33 AM, Cory Quammen <cory.quam...@kitware.com> wrote: > Hi Bill, > > Let's keep the discussion on the mailing list so others can benefit > from and contribute to the conversation. > > Ken, > > Is the ATI Radeon HD 4200 too old for the OpenGL2 backend? It's circa > 2010, I believe. It looks like it can support OpenGL 3.2 with Shader > 4.1. I'm wondering if there is maybe a subtle shader compilation issue > on the ATI hardware? > > Thanks, > Cory > > > > On Mon, Feb 13, 2017 at 11:28 AM, Bill Greene <w.h.gre...@gmail.com> > wrote: > > Thanks for getting back to me so quickly! > > > > The graphics device is an ATI Radeon HD 4200. > > > > Nothing is written to the Paraview "Output Messages" window. > > Is there someplace else I should look? > > > > Bill > > > > On Mon, Feb 13, 2017 at 11:14 AM, Cory Quammen <cory.quam...@kitware.com> > wrote: > >> Hi Bill, > >> > >> It sounds like the rendering backend isn't fully supported on your > >> graphics card/driver combo. What kind of card is it? Are you getting > >> any error messages? > >> > >> Thanks, > >> Cory > >> > >> On Mon, Feb 13, 2017 at 11:09 AM, Bill Greene <w.h.gre...@gmail.com> > wrote: > >>> I have been using Paraview 4 on my windows 7 computer for quite a while > >>> now but wanted to upgrade to Paraview 5. > >>> > >>> Installation appeared to work fine but when I display a model I am > seeing > >>> a rendering problem that I don't see in Paraview 4. If > Representation=Surface > >>> and Coloring=Solid Color, the object is black regardless of how the > >>> color is defined. If Rep=Surface with Edges, the edges do appear over > the > >>> black object. If I select one of the results vectors under Coloring, > the > >>> color bar is displayed and looks correct; but the object remains black. > >>> > >>> I know that the graphics card in the computer is somewhat old ( the > drivers > >>> are the latest for the device) but have no idea if that is related to > >>> the problem > >>> I'm seeing. > >>> > >>> I'm wondering if others have encountered this problem or if there is > >>> some setting I > >>> can change to avoid it. > >>> > >>> Thanks, > >>> > >>> Bill Greene > >>> ___ > >>> 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 > >> > >> > >> > >> -- > >> Cory Quammen > >> Staff R Engineer > >> Kitware, Inc. > > > > -- > Cory Quammen > Staff R Engineer > Kitware, Inc. > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] what is the difference between OpenGL rendering backend and OpenGL2 rendering backend when they communicate with the X Window System?
OPenGL 4.4 is plenty and that card should support the new backend. My first thought would be to try updating the nvidia driver as it is pretty old. On Mon, Feb 13, 2017 at 5:23 AM, 张驭洲 <yzhzh...@ipe.ac.cn> wrote: > > > Hello, > > For a long time I have a problem using ParaView 5.2.0 in the client-server > mode. However, at the same time, I can use ParaView 4.4.0 in this mode on > the same machine. Recently I have built several different versions of > ParaView, including 4.3.1, 4.4.0, 5.1.2, 5.2.0, on the same machine and > with almost the same compilation options (the only difference among the > buildings is the rendering backend), and I found that when built with > OpenGL rendering backend, all the versions, including 5.1.2 and 5.2.0, can > work normally, in both standalone mode and client-server mode. But when > 5.1.2 and 5.2.0 are built with OpenGL2 rendering backend, they can't work. > The machine is a node of a HPC system, so I connect to it via realVNC. If I > start the paraview execuble by typing ./paraview, I get this output: > > Segmentation fault (core dumped) > > If I connect to the node via ssh, and type ./paraview , then I get: > > paraview: c annot connect to X server > > I know this is because I didn't start the X for the paraview, this test is > just for comparison. > > If I connect to the node via ssh, and type ./paraview -display :0 , then I > get: > > X Error: GLXBadContext 144 > Extension:135 (Uknown extension) > Minor opcode: 5 (Unknown request) > Resource id: 0x36001bc > ERROR: In > /root/Desktop/ParaView-v5.2.0/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, > line 629 > vtkXOpenGLRenderWindow (0x339c550): GLEW could not be initialized. > > > Segmentation fault (core dumped) > > If I connect to the node via ssh, and type ./pvserver and connect to it > from the paraview GUI on my PC, then I get: > > Display is not accessible on the server side. > > Remote rendering will be disabled. > > > This means if I dont't use the rendering feature on the node, other > features of the ParaView can be used normally. > > > If I connect to the node via ssh, and type ./pvserver -display :0, and > connect to it from the paraview GUI on my PC, then I get lots of errors on > the client side, like this: > > ERROR: In /home/buildslave/dashboards/buildbot/paraview-pvbinsdash- > linux-shared-release_opengl2_qt4_superbuild/source- > paraview/VTK/Common/System/vtkSocket.cxx, line 572 > vtkClientSocket (0x1973c70): Socket error in call to send. Broken pipe. > > And on the server side, the errors are: > > X Error of failed request: GLXBadContext > Major opcode of failed request: 135 (GLX) > Minor opcode of failed request: 5 (X_GLXMakeCurrent) > Serial number of failed request: 28 > Current serial number in output stream: 28 > > From all the tests, I think it's reasonable to guess that the problem lies > in the X Window system and the OpenGL2 rendering backend. The operation > system of the node is CentOS 6.3 and the X Window System was installed > using "yum groupinstall". The GPU on the node is Tesla C2050 and the driver > version is 331.67. The output from "glxinfo | grep OpenGL" is as follow: > > OpenGL vendor string: NVIDIA Corporation > OpenGL renderer string: Tesla C2050/PCIe/SSE2 > OpenGL version string: 4.4.0 NVIDIA 331.67 > OpenGL shading language version string: 4.40 NVIDIA via Cg compiler > OpenGL extensions: > > Is there anything wrong with the setting? Why does ParaView with OpenGL > rendering backend work on it but that with OpenGL2 not work? > > Any help or reply is highly appreciated! > > -Zhang > > > > > > > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original m
Re: [Paraview] Rendering Backend OpenGL2 & PV 5.2.0-RC4 & SurfaceLic --> Problem...
Thanks so much for the example. I have a VTK topic that I believe will fix the issue here: https://gitlab.kitware.com/vtk/vtk/merge_requests/2463 It fails three of the current paraview LIC tests but with images that still look reasonable (although one looks dark to me). The changes only impact two files. Your example no longer hangs with these changes. If you have a chance to test it on your real data or other cases that would help me feel more confident about the change. Thanks Ken On Wed, Feb 8, 2017 at 9:21 AM, Andy Smith <agsmith...@gmail.com> wrote: > Ken, > > I've attached a small example file and script that demonstrates the > problem. > > The example dataset is a multiblock unstructured grid with two blocks. > The script attempts to create two images of slices through the dataset. At > the first slice position data from both blocks are in the slice. At the > second slice position only data from one block is part of the slice. This > works in serial and parallel (two processors) using pvbatch when not using > surface LIC and in serial when using surface LIC with the latest ParaView > from the git repo. In parallel, the surface LIC hangs when creating the > second image. This script works in parallel with surface LIC when using > version 4.4.0. > > As an aside, I call the function to ensure that the surface LIC plugin is > loaded at the beginning of the script. When I do this I get warnings about > "Replacing existing representation for key: Surface LIC". I assume this is > because in my build I turned on the option to load the surface LIC plugin > by default. Is there a way in Python to check if a plugin is loaded and > skip this step if that is the case? > > Let me know if I can provide any additional information. > > -Andy > > On Tue, Feb 7, 2017 at 8:32 AM, Ken Martin <ken.mar...@kitware.com> wrote: > >> Thanks Andy, just to make sure I understand the issue. Is the case that >> one processor has no data, or is it that it has data, but it is outside the >> current view? >> >> Thanks >> Ken >> >> On Thu, Feb 2, 2017 at 5:14 PM, Andy Smith <agsmith...@gmail.com> wrote: >> >>> I've tested this with the latest ParaView and it does seem to run much >>> faster. >>> I am having a problem when running in parallel though. If one processor >>> does not have anything to display, the rendering hangs. >>> Related to that, what routine actually calls >>> vtkCompositeLICHelper::RenderPiece? >>> The process that does not have anything to display never gets to that >>> function but the other processes do. In that function there are MPI calls >>> where the rendering hangs. >>> >>> As a reply to Chuck: I can use EGL in some instances but unfortunately >>> not all of our machine have GPUs so software rendering is still required. >>> >>> Thanks again for all the help. >>> >>> On Mon, Jan 23, 2017 at 12:45 PM, Ken Martin <ken.mar...@kitware.com> >>> wrote: >>> >>>> There is a VTK topic now that should fix this regression. With this >>>> change OpenGL2 LIC seems to run much faster (at least 10X). >>>> >>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/2419 >>>> >>>> Hopefully it will test out OK and get merged into VTK and then merged >>>> into ParaView. >>>> >>>> On Mon, Dec 12, 2016 at 11:38 AM, Andy Smith <agsmith...@gmail.com> >>>> wrote: >>>> >>>>> Ken, >>>>> >>>>> You are correct in your assumption about my dataset; it is multiblock >>>>> unstructured data. Adding a MergeBlocks filter to my slice does improve >>>>> the 5.2.0 with OpenGL2 significantly. >>>>> With that change the performance of 5.2.0 with OpenGL2 is on the same >>>>> order of magnitude as 5.2.0 with OpenGL and with 4.4.0, though the 5.2.0 >>>>> variants are still slower than 4.4.0. >>>>> >>>>> I realized after posting that my comparison is not exactly apples to >>>>> apples - my build of 5.2.0 required updates to mesa (13.0.0) compared with >>>>> the version I used for 4.4.0 (11.2.0). >>>>> I will recompile 4.4.0 with the same mesa version I used with 5.2.0 >>>>> and report back. >>>>> >>>>> Thank you for your input. >>>>> >>>>> -Andy >>>>> >>>>> On Fri, Dec 9, 2016 at 3:44 PM, Ken Martin <ken.mar...@kitware.com> >>>>> wrote: >
Re: [Paraview] Rendering Backend OpenGL2 & PV 5.2.0-RC4 & SurfaceLic --> Problem...
Thanks Andy, just to make sure I understand the issue. Is the case that one processor has no data, or is it that it has data, but it is outside the current view? Thanks Ken On Thu, Feb 2, 2017 at 5:14 PM, Andy Smith <agsmith...@gmail.com> wrote: > I've tested this with the latest ParaView and it does seem to run much > faster. > I am having a problem when running in parallel though. If one processor > does not have anything to display, the rendering hangs. > Related to that, what routine actually calls vtkCompositeLICHelper:: > RenderPiece? > The process that does not have anything to display never gets to that > function but the other processes do. In that function there are MPI calls > where the rendering hangs. > > As a reply to Chuck: I can use EGL in some instances but unfortunately > not all of our machine have GPUs so software rendering is still required. > > Thanks again for all the help. > > On Mon, Jan 23, 2017 at 12:45 PM, Ken Martin <ken.mar...@kitware.com> > wrote: > >> There is a VTK topic now that should fix this regression. With this >> change OpenGL2 LIC seems to run much faster (at least 10X). >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/2419 >> >> Hopefully it will test out OK and get merged into VTK and then merged >> into ParaView. >> >> On Mon, Dec 12, 2016 at 11:38 AM, Andy Smith <agsmith...@gmail.com> >> wrote: >> >>> Ken, >>> >>> You are correct in your assumption about my dataset; it is multiblock >>> unstructured data. Adding a MergeBlocks filter to my slice does improve >>> the 5.2.0 with OpenGL2 significantly. >>> With that change the performance of 5.2.0 with OpenGL2 is on the same >>> order of magnitude as 5.2.0 with OpenGL and with 4.4.0, though the 5.2.0 >>> variants are still slower than 4.4.0. >>> >>> I realized after posting that my comparison is not exactly apples to >>> apples - my build of 5.2.0 required updates to mesa (13.0.0) compared with >>> the version I used for 4.4.0 (11.2.0). >>> I will recompile 4.4.0 with the same mesa version I used with 5.2.0 and >>> report back. >>> >>> Thank you for your input. >>> >>> -Andy >>> >>> On Fri, Dec 9, 2016 at 3:44 PM, Ken Martin <ken.mar...@kitware.com> >>> wrote: >>> >>>> I have not had time to look into this, but my quick guess is that you >>>> have a multiblock dataset with a lot of blocks. Can you try merging the >>>> blocks all together somehow into one block and see if the rendering speed >>>> improves? >>>> >>>> On Tue, Nov 15, 2016 at 5:35 AM, Stefan Melber <stefan.mel...@dlr.de> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> i have a problem which is there in all RCs (1-4) of current ParaView: >>>>> if i compile the RenderingBackend to "OpenGL2" and use SurfaceLic the >>>>> visualization time goes up from a few seconds (with "OpenGL") to many >>>>> minutes and the memory consumption from a few GByte to approx 100 GByte. >>>>> Switching back to OpenGL any thing is fine. Without SurfaceLIC the OpenGL2 >>>>> works although fine for me. >>>>> >>>>> Has any one tested OpenGL2 with SurfaceLIC-Plugin the last time and >>>>> has (the same) problems? >>>>> >>>>> o Kernel 4.7.6-1 / x86-64 >>>>> o Quadro 4000 >>>>> o NVidia driver v367.57 >>>>> o PV 5.2.0 RC1 - RC4 >>>>> >>>>> Best regards, >>>>> >>>>>Stefan >>>>> >>>>> >>>>> >>>>> ___ >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ken Martin PhD >>>> Chairman & CFO >>>
Re: [Paraview] Paraview 5.2.0 compilation with support for HMD and Python
Hi Guillaume, I hope to get some time to clean up some issues with the code and to merge it into PV master. It will probably be a bit though as right now I am taking another pass at the OpenVR VTK code which it is based on to add a medical (volume rendering) example and a few options such as a floor etc. Once that is done, I'll try to get to another pass on the PV code and get it merged. For now the code can be found at https://gitlab.kitware.com/ken-martin/paraview/commits/add_vr_2 but I believe that is old and not rebased to 5.2.0. Best bet would be to rebase that to 5.2.0 and then update VTK to master to get the latest OpenVR SDK fixes and then hope the two work/compile together. On Tue, Jan 10, 2017 at 9:23 AM, Cory Quammen <cory.quam...@kitware.com> wrote: > Hi Guillaume, > > Ken Martin is responsible for this cool version of ParaView. I'm not > sure that the code is ready for release just yet - Ken can tell you > more. > > Thanks, > Cory > > On Tue, Jan 10, 2017 at 5:55 AM, Guillaume Jacquenot > <guillaume.jacque...@gmail.com> wrote: > > I have seen that Kitware developers have proposed a ParaView version with > > support for Oculus Rift and HTC Vive HMD. > > And it looks awesome, and opens a wide range of opportunities. > > > > https://blog.kitware.com/taking-paraview-into-virtual-reality/ > > > > However, the proposed version does not embed Python scripting > possibilities. > > > > I would like to benefit from these functionnalities. > > > > Can anyone give me some advice on: > > - where to find the source code with the support for HMD > > - how to compile to the code with Python support > > > > The best would be a link to an installation file, but I am ready to > compile > > it! > > > > Thanks > > > > Guillaume Jacquenot > > > > ___ > > 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 > > > > > > -- > Cory Quammen > Staff R Engineer > Kitware, Inc. > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] [EXTERNAL] Re: Newer object always in front in Render View
Possibly unrelated, but we did see this odd behavior on some systems with a paraview built against Qt5. It seems it lacked a depth buffer in that case. On Wed, Jan 4, 2017 at 12:51 PM, Robert Sawko <robertsa...@gmail.com> wrote: > > On this computer I have two PV installed. One from AUR and one compiled > from > OpenFOAM third party directory. The OpenFOAM works fine. It does say > "Legacy > Rendering Backend" in the title bar which may or may not be significant. > The > computer is running NVidia drivers and the card is Quadro. But I am > reproducing > this problem on another Arch machine with some Intel integrated graphics > card. > > I'll try now Alan's suggestion and download it from Kitware directly. > > Robert > -- > The finger of icy death > https://www.youtube.com/watch?v=WyWn1XJ9kTE > http://en.wikipedia.org/wiki/Brinicle > ___ > 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 > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Still Render in PV5.2.0 takes longer time than in PV4.4.0
For the first render of points your numbers seem reasonable. For subsequent renders you will find different tradeoffs on the old backend. Display Lists are typically slower for a first render but faster on subsequent renders. With them turned off the first render is fast but subsequent renders are not any faster. Subsequent renders with OpenGL2 should be fairly fast. On Tue, Jan 3, 2017 at 8:13 PM, 张驭洲 <yzhzh...@ipe.ac.cn> wrote: > > > Thank you all! > > I'm using Kitware's binaries and 4.4 is with OpenGL 1 and 5.2 is with > OpenGL 2. Now that this option has no impact on OpenGL2 backend, is there > any other option (besides those mentioned in the User's Guide) that can > improve the performance of PV 5.2? In my case, by turning off the display > list, the overall performance of PV 4.4 is similar to that of PV 5.2. > > -Zhang > > -原始邮件- > *发件人:* "Ken Martin" <ken.mar...@kitware.com> > *发送时间:* 2017年1月3日 星期二 > *收件人:* "Utkarsh Ayachit" <utkarsh.ayac...@kitware.com> > *抄送:* "David E DeMarle" <dave.dema...@kitware.com>, "张驭洲" < > yzhzh...@ipe.ac.cn>, "paraview@paraview.org" <paraview@paraview.org> > *主题:* Re: [Paraview] Still Render in PV5.2.0 takes longer time than in > PV4.4.0 > > For the new OpenGL2 backend setting ImmediateModeRendering or > UseDisplayLists or something similar has no impact. Those concepts are part > of the legacy OpenGL API. So you should see no difference in timings with > them turned on or off with the new OpenGL backend. > > On Tue, Jan 3, 2017 at 9:42 AM, Utkarsh Ayachit < > utkarsh.ayac...@kitware.com> wrote: > >> On Tue, Jan 3, 2017 at 9:10 AM, David E DeMarle >> <dave.dema...@kitware.com> wrote: >> > Is this with OpenGL1 or 2 back end? If you are using Kitware's binaries >> 4.4 >> > will be OpenGL1 and 5.2 will be OpenGL2. If you built from source or >> got it >> > from a distro then it might be otherwise. >> >> A way to tell which type of build you're using is to loo at the title >> bar. For OpenGL1, the title bar says "Legacy Rendering Backend". Such >> a suffix is missing for OpenGL2 build. >> >> Utkarsh >> ___ >> 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 >> > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 <(518)%20371-3971> > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Still Render in PV5.2.0 takes longer time than in PV4.4.0
For the new OpenGL2 backend setting ImmediateModeRendering or UseDisplayLists or something similar has no impact. Those concepts are part of the legacy OpenGL API. So you should see no difference in timings with them turned on or off with the new OpenGL backend. On Tue, Jan 3, 2017 at 9:42 AM, Utkarsh Ayachit <utkarsh.ayac...@kitware.com > wrote: > On Tue, Jan 3, 2017 at 9:10 AM, David E DeMarle > <dave.dema...@kitware.com> wrote: > > Is this with OpenGL1 or 2 back end? If you are using Kitware's binaries > 4.4 > > will be OpenGL1 and 5.2 will be OpenGL2. If you built from source or got > it > > from a distro then it might be otherwise. > > A way to tell which type of build you're using is to loo at the title > bar. For OpenGL1, the title bar says "Legacy Rendering Backend". Such > a suffix is missing for OpenGL2 build. > > Utkarsh > ___ > 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 > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Rendering Backend OpenGL2 & PV 5.2.0-RC4 & SurfaceLic --> Problem...
I have not had time to look into this, but my quick guess is that you have a multiblock dataset with a lot of blocks. Can you try merging the blocks all together somehow into one block and see if the rendering speed improves? On Tue, Nov 15, 2016 at 5:35 AM, Stefan Melber <stefan.mel...@dlr.de> wrote: > Hi, > > > i have a problem which is there in all RCs (1-4) of current ParaView: if i > compile the RenderingBackend to "OpenGL2" and use SurfaceLic the > visualization time goes up from a few seconds (with "OpenGL") to many > minutes and the memory consumption from a few GByte to approx 100 GByte. > Switching back to OpenGL any thing is fine. Without SurfaceLIC the OpenGL2 > works although fine for me. > > Has any one tested OpenGL2 with SurfaceLIC-Plugin the last time and has > (the same) problems? > > o Kernel 4.7.6-1 / x86-64 > o Quadro 4000 > o NVidia driver v367.57 > o PV 5.2.0 RC1 - RC4 > > Best regards, > >Stefan > > > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
[Paraview] ParaView 5.2 for Oculus and OpenVR/Vive
There is a new VR version of ParaView based on the 5.2.0 release available at www.paraview.org/download under 5.2/Experimental Demos. In addition to all the 5.2 paraview changes it includes: - big performance fix where the VR rendering was being held up by Vsync limits on the screen window - performance fix when grabbing and moving objects in paraview VR - a few other small performance optimizations to improve tracking accuracy and reduce latency Thanks Ken -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] RAW (binary) file import issues
I believe Visual studio 2010 does not properly handle file seeks/etc beyond 32 bit even on 64 bit builds. If you are using VS 2010 or earlier that is possibly the issue. I believe it is fixed in VS 2013 and later. On Tue, Nov 22, 2016 at 5:11 PM, Moreland, Kenneth <kmo...@sandia.gov> wrote: > Although we have certainly run into issues with communicating large > messages, I’m not sure this is the issue with MPI-I/O. File sizes and > linear offsets use a type MPI_Offset, which according to the specification > should be large enough to hold the size of any file supported by the file > system. Although it is true that creating the 3D subarray uses 32-bit > indices, those are for each of the separate dimensions, and 2000 falls well > below that limit. > > > > Besides, it looks like that error happens when checking an ifstream > object, so it looks like the reader is bypassing the MPI-I/O path anyway. > > > > I would follow Berk’s suggesting of looking into the filesystem before > diving into the guts of MPI-I/O. > > > > -Ken > > > > *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of *Burlen > Loring > *Sent:* Tuesday, November 22, 2016 12:55 PM > *To:* Geveci, Berk (External Contact) <berk.gev...@kitware.com>; Keyes > S.D. <s.d.ke...@soton.ac.uk> > *Cc:* paraview@paraview.org > *Subject:* [EXTERNAL] Re: [Paraview] RAW (binary) file import issues > > > > I've hit that before. the RAW reader uses MPI-I/O, and MPI uses signed int > everywhere in its API, so there are limits that you end up hitting. For > instance to partition the data among processors one must give MPI-I/O the > starting offset of the data in the file as a signed int, and that is > limited to 2^31. > > Burlen > > On 11/22/2016 11:20 AM, Berk Geveci wrote: > > Hmmm that happens to be around 4 GB which makes me wonder if there is a > limit somewhere in that reader... Any chance you can try this on a Linux > machine? > > > > On Thu, Nov 17, 2016 at 10:30 AM, Keyes S.D. <s.d.ke...@soton.ac.uk> > wrote: > > Dear all, > > I am encountering issues when trying to import large 8 bit RAW volumes to > Paraview 5.1.2 (64 bit). > > The file I wish to import has xyz dimensions of 2000x2000x1920 voxels > (Unsigned char), 7.5GB. I am running a machine with 192 GB RAM and 12 CPU > cores. > > I can import up to a 2000x2000x1000 crop of this file, but I encounter the > following message when I attempt larger z dimensions: > > ERROR: In C:\bbd\df0abce0\source-paraview\VTK\IO\Image\vtkImageReader2.cxx, > line 592 > > vtkPVImageReader (07767F90): Initialize: Could not open file > \\cseg_2\ERC\SLS_201606\Myco_2\CT2PpR3h1_\Hyphalseg_Raw_ > 2000_2000_1920_8bit_SKELETON_FILT_PARAVIEW_TEST.raw > > > I cannot find an obvious memory ceiling within the paraview settings - any > ideas as to whether there is some effective upper limit to import file size? > > Sam > > Samuel D Keyes, MEng, PhD > New Frontiers Fellow > Bioengineering / μVIS Centre for Computed Tomography > University of Southampton > E: s.d.ke...@soton.ac.uk<https://www.outlook.soton.ac.uk/owa/re > dir.aspx?SURL=dhUg3da8XR77LeItLDzJQwhAwmH0Wx6PHrXeKfxx2tOD3LCr737TCG0AYQBp > AGwAdABvADoAUwAuAEQALgBLAGUAeQBlAHMAQABzAG8AdABvAG4ALgBhAGMA > LgB1AGsA=mailto%3aS.D.Keyes%40soton.ac.uk> > T: 07898720248 > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/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 > > > > > > > ___ > > 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 > > > > ___________ > 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
Re: [Paraview] Polyhedral Cells: Rendering Problem with OpenGL...
Basically it is OpenGL, in that OpenGL doesn't automatically tessellate concave polygons. Making VTK always examine every polygon to determine if it is concave would be a performance hit for everyone, so we leave it up to developers to use a triangle filter if they need it. Thanks Ken On Tue, Oct 18, 2016 at 9:11 AM, Stefan Melber <stefan.mel...@dlr.de> wrote: > Hi Martin, > > i tried the triangle filter in all cases - and yes - i works in all three > cases. > > So is this "problem" of concave polygons inside VTK or in OpenGL? > > Best regards, > > Stefan > > I'm not sure if this is your issue, but you might try using a triangle > filter on your data. For OpenGL we do not guarantee correct rendering of > concave polygons. The triangle filter will convert a concave polygon into > convex triangles which should render correctly. > > On Tue, Oct 18, 2016 at 2:20 AM, Stefan Melber <stefan.mel...@dlr.de> > wrote: > >> Hi, >> >> i found a rendering problem with cuts through polyhedral cells depending >> on which rendering backend is used. For example in PV 5.1.2 compiled with >> >> VTK_RENDERING_BACKEND = OpenGL >> >> a cut looks like error.opengl.v5_1_2.png - there is a wrong shading and >> some facets coming from the wrong starting point. >> >> Switching to OpenGL2 everything is fine (error.opengl2.v5_1_2.png). This >> problem is the same with ParaView 5.2.0RC1 and OpenGL or OpenGL2 - however >> there seems to be an additional (smaller) problem using OpenGL2: there are >> some lines drawn outside of the shell - see error.opengl2.v5_2_0rc1.png >> (cutted on a different position). >> >> The example cell is for testing is attached as "error.vtk" - cut e.g. in >> x-direction on different positions to get the described effects. >> >> Best regards, >> >>Stefan >> >> >> System: >> o OpenSuse Tumbleweed >> o Kernel: 4.7.6-1 >> o Linux 64 bit >> o NVidia Quadro 4000 / NV Driver v367.44 >> >> >> >> >> >> _/ *Dr. Stefan Melber-Wilkending* >>_/_/ >> _/ _/ Deutsches Zentrum für Luft- >> _/_/_/_/_/_/_/_/_/_/ und Raumfahrt e.V. (DLR) >>_/_/_/_/ >> _/_/_/_/ German Aerospace Center >>_/_/_/_/_/_/_/_/_/_/ Institute of Aerodynamics >> _/ _/ _ _ and Flow Technology >> _/_/ | \ | |_| Transport Aircraft Branch >> _/ |_/ |_ | \ >> Lilienthalplatz 7 >> Fields of activities: 38108 Braunschweig >> Germany >> o Numerical Windtunnel Simulation >> o Aero-Acoustic Windtunnel DesignPhone : +49 531/295-2836 >> o Numerical Optimization Fax. .: +49 531/295-2914 >> o Visualization Techniques >> o High-Lift Aerodynamics Email : stefan.mel...@dlr.de >> o Glider-Aerodynamics Web ..: http://www.dlr.de/AS >> >> >> >> >> >> _______ >> 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 >> >> > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachm
Re: [Paraview] Polyhedral Cells: Rendering Problem with OpenGL...
I'm not sure if this is your issue, but you might try using a triangle filter on your data. For OpenGL we do not guarantee correct rendering of concave polygons. The triangle filter will convert a concave polygon into convex triangles which should render correctly. On Tue, Oct 18, 2016 at 2:20 AM, Stefan Melber <stefan.mel...@dlr.de> wrote: > Hi, > > i found a rendering problem with cuts through polyhedral cells depending > on which rendering backend is used. For example in PV 5.1.2 compiled with > > VTK_RENDERING_BACKEND = OpenGL > > a cut looks like error.opengl.v5_1_2.png - there is a wrong shading and > some facets coming from the wrong starting point. > > Switching to OpenGL2 everything is fine (error.opengl2.v5_1_2.png). This > problem is the same with ParaView 5.2.0RC1 and OpenGL or OpenGL2 - however > there seems to be an additional (smaller) problem using OpenGL2: there are > some lines drawn outside of the shell - see error.opengl2.v5_2_0rc1.png > (cutted on a different position). > > The example cell is for testing is attached as "error.vtk" - cut e.g. in > x-direction on different positions to get the described effects. > > Best regards, > >Stefan > > > System: > o OpenSuse Tumbleweed > o Kernel: 4.7.6-1 > o Linux 64 bit > o NVidia Quadro 4000 / NV Driver v367.44 > > > > > > _/ *Dr. Stefan Melber-Wilkending* >_/_/ > _/ _/ Deutsches Zentrum für Luft- > _/_/_/_/_/_/_/_/_/_/ und Raumfahrt e.V. (DLR) >_/_/_/_/ > _/_/_/_/ German Aerospace Center >_/_/_/_/_/_/_/_/_/_/ Institute of Aerodynamics > _/ _/ _ _ and Flow Technology > _/_/ | \ | |_| Transport Aircraft Branch > _/ |_/ |_ | \ > Lilienthalplatz 7 > Fields of activities: 38108 Braunschweig > Germany > o Numerical Windtunnel Simulation > o Aero-Acoustic Windtunnel DesignPhone : +49 531/295-2836 > o Numerical Optimization Fax. .: +49 531/295-2914 > o Visualization Techniques > o High-Lift Aerodynamics Email : stefan.mel...@dlr.de > o Glider-Aerodynamics Web ..: http://www.dlr.de/AS > > > > > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView
I finally did get around to this issue and have completely reworked the CompositePolyDataMapper2 for the OpenGL2 backend. Now there is only the fast path and your original dataset ***should*** render quickly with OpenGL2. These changes were merged into VTK last week and hopefully most of the kinks have been worked out. In terms of benchmarks I did some testing and with the recent changes I made these are the numbers I am seeing for six different test cases on an nvidia based laptop GPU. Thanks! Ken OpenGL1 versus 2 CompositePolyDataMapper2 OpenGL1 New OpenGL2 Improvement Test First Average Frame Rate First Average Frame Rate First Average MixedGeometryCellScalars 3.75 0.319 3.1 0.11 0.0131 76.3 3409% 2435% CellScalars 0.3 0.0433 23.1 0.094 0.002 500.0 319% 2165% Scalars 0.4 0.0394 25.4 0.083 0.001875 533.3 482% 2101% Default 0.293 0.039 25.6 0.11 0.00215 465.1 266% 1814% MixedGeometryEdges 6.586 0.5 2.0 0.11 0.01567 63.8 5987% 3191% Average 2093% 2341% On Tue, Jan 5, 2016 at 12:51 PM, Ken Martin <ken.mar...@kitware.com> wrote: > Nice job Adam! > > I've though about your issue some more and I think the best solution is to > revamp the vtkCompositePolyDataMapper2 to work a little differently. > Basically always have it group together blocks that have the same > properties and then render each of them with a helper mapper. That would > give us great performance in both cases. I have added it to the OpenGL2 > ToDo list just, not sure how soon someone will get to it as the old code > works, it just isn't optimal in all cases. > > Thanks! > Ken > > > > On Tue, Jan 5, 2016 at 12:39 PM, Adam Lyon <l...@fnal.gov> wrote: > >> Hi - Just thought I'd let you all know that I've finally made progress on >> this problem. To recap, I have a MultiBlockDataSet (MBDS) containing >> PolyData objects. The PolyData objects don't all have the same attributes >> (some have Normals, some don't; some have particular FieldData, others >> don't). This "heterogeneous" MBDS reflects the visualization data I get >> from the Geant4 simulation program - some things have particular attributes >> and others don't. >> >> As you (Ken & Utkarsh) pointed out, such a heterogenous MBDS triggers a >> generic renderer in ParaView v5/OpenGL2 unless every block within the MBDS >> has the same structure. The generic renderer is extremely slow, and it >> makes interacting with the visualization in ParaView painful (e.g. a few >> frames per second or less). >> >> I now have a filter (I should fix my ParaView Source that creates the >> MBDS - but that'll be for later) that runs through the MBDS and makes it >> homogeneous - that is it removes Normals and TCoords (only a very few >> PolyData have them) and adds missing FieldData with defaults. This triggers >> the fast renderer - and boy it's *a lot* faster. 30x - 200x faster frame >> rates compared to the generic renderer. The fast renderer is at least many >> times faster than the OpenGL1 renderer in ParaView v4.4. >> >> I'm quite happy with this solution and am glad I can finally use the new >> features in ParaView v5/OpenGL2. Woohoo! >> >> I'm wondering if other people are going to hit this generic renderer >> slowness.. I added some code to my build of ParaView v5 in >> vtkCompositePolyDataMapper2.cxx that std::cout's a message when the >> generic renderer is triggered and why (e.g. heterogeneous Normals, TCoords, >> Scalars, etc). I found that to be very helpful. Perhaps the render >> annotation could show such a message (e.g. in vtkPVRenderView). >> >> Thanks again for your help!! And Happy New Year!! -- Adam >> >> *--* >> >> *Adam L. Lyon* >> *Scientist; Associate Division Head for Systems for Scientific >> Applications* >> >> Scientific Computing Division & Muon g-2 Experiment >> Fermi National Accelerator Laboratory >> 630 840 5522 office >> www.fnal.gov >> l...@fnal.gov >> >> Connect with us! >> Newsletter <http://www.fnal.gov/pub/today/> | Facebook >> <https://www.facebook.com/Fermilab> | Twitter >> <https://twitter.com/Fermilab> >> >> On Wed, Dec 16, 2015 at 1:46 PM, Ken Martin <ken.mar...@kitware.com> >> wrote: >> >>> This code is all new hence the change. On the plus side if you moved >>> from 4000 blocks of 10 triangles each to 4000 blocks of 1 triangles >>> each the rendering performance would probably not slow down. The overhead >>> is all in starting and stopping each of those 4000 mappers. >>> >>> The old backend wrote everything out into a displaylist and the OpenGL >>> drive
Re: [Paraview] PV Web scrollwheel for zoom, wrong legend
left mouse does work as zoom in vtk.js FWIW - Ken
On Wed, Aug 17, 2016 at 7:32 PM, Sebastien Jourdain <
sebastien.jourd...@kitware.com> wrote:
> vtk.js interaction does not currently implement zooming. So the current
> behavior is expected.
>
> What are you trying to do with vtk.js and salome? vtk.js has not been
> released yet and is a pure JavaScript/client library.
>
>
>
> On Wed, Aug 17, 2016 at 3:18 PM, Daniel Zuidinga <i...@seoaachen.de>
> wrote:
>
>> shouldn't work scroll wheel in vtk.js? e.g. here
>> https://kitware.github.io/vtk-js/examples/HttpSceneLoader.html
>> I have to compile the whole sources? I use pv of salome meca. I hope it
>> isn't to complicated and cpu intensive.
>>
>>
>> Am 17.08.2016 um 22:32 schrieb Sebastien Jourdain:
>>
>> I guess ParaView is missing more code on the server side. ;-)
>> This time, it will be in the C++.
>>
>>
>> ${ParaView-src}/VTK/Web/Core/vtkWebApplication.cxx =>
>> vtkPVWebApplication::HandleInteractionEvent
>>
>> vs
>>
>> ${ParaView-src}/Web/Core/vtkPVWebApplication.cxx =>
>> vtkWebApplication::HandleInteractionEvent
>>
>> The VTK one has:
>>
>> // Handle scroll action if any
>> if(event->GetScroll()) {
>> iren->SetEventInformation(0, 0, ctrlKey, shiftKey,
>> event->GetKeyCode(), 0);
>> iren->MouseMoveEvent();
>> iren->RightButtonPressEvent();
>> iren->SetEventInformation(0, event->GetScroll()*10, ctrlKey,
>> shiftKey, event->GetKeyCode(), 0);
>> iren->MouseMoveEvent();
>> iren->RightButtonReleaseEvent();
>> this->Internals->ImageCache[view].NeedsRender = true;
>> return true;
>> }
>>
>> If you got it working, could you submit a pull request on our gitlab and
>> assign it to me so those fix could be part of PV 5.2?
>>
>> Thanks,
>>
>> Seb
>>
>> On Wed, Aug 17, 2016 at 2:08 PM, Daniel Zuidinga <i...@seoaachen.de>
>> wrote:
>>
>>> I added the lines but scroll wheel does not work
>>>
>>>
>>>> Look at ${pv_src}/Web/Python/paraview/web/protocols.py
>>>> #ParaViewWebMouseHandler
>>>> vs ${pv_src}/VTK/Web/Python/vtk/web/protocols.py #vtkWebMouseHandler
>>>>
>>>> it seems the paraview one is missing:
>>>>
>>>> if event.has_key("scroll"):
>>>> pvevent.SetScroll(event["scroll"])
>>>>
>>>> Just add it to your paraview python file.
>>>>
>>>>
>>>
>>
>>
>
> ___
> 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
>
>
--
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee. Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message. Thank you.
___
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
Re: [Paraview] Paraview compatibility questions
I'm pretty sure it will not work with the new OpenGL2 backend, it may work with the old OpenGL backend as microsoft provides a software implementation of opengl 1.4 with their OSs. That card is not really intended for graphics so the rendering performance may be a bit slow. On Mon, Jul 25, 2016 at 1:10 PM, Craig Christensen < craig.christen...@ucalgary.ca> wrote: > Hello all, > > I am a fairly new user of Paraview, and have been floored at how powerful > of a tool it is. I would like to install it on my research group's remote > desktop; however, my colleagues in IT are not comfortable with installing > it until I have confirmation that it is compatible with oursystem. > > First off, has anyone successfully installed Paraview using the Windows > Server 2008 R2 Enterprise (Service Pack 1) operating system? If so, what > version of Paraview was installed? > > Second, I am having a hard time finding documentation on whether the > remote desktop's graphics card is OpenGL compatible. Has anyone using > Paraview had success with the Matrox G200eW 16MB DDR2 graphics card? > > Thanks in advance for your help. > -- > *Craig W. Christensen* > M.Sc. Candidate (Geoscience), University of Calgary > BSc.Eng. (Geological), Queen's University at Kingston > > http://ca.linkedin.com/pub/craig-christensen/21/240/19/en>> > > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Segfault with OpenGL2
As I understand it VirtualGL should transparently forward OpenGL/GLX/etc calls from the server to the client so that the client GPU is used. So my guess would be to first try running PV on the client and see if it works. If that seems to work fine then you know your client graphics supports PVs use of OpenGL and the issue could be in VirtualGL or some PV/VirtualGL interaction. Ken On Fri, Apr 8, 2016 at 3:20 AM, Harald Klimach <har...@klimachs.de> wrote: > Hi there, > > I try to use the OpenGL2 Rendering backend in Paraview 5.0.1 on Archlinux > with an nvidia graphics card. > The setup involves running paraview with VirtualGL in a x2go session, and > I always get the following error: > > ——— > ERROR: In > /home/gk772/abs/paraview/src/ParaView-v5.0.1-source/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, > line 575 > vtkXOpenGLRenderWindow (0x42e8540): GLEW could not be initialized. > > > ERROR: In > /home/gk772/abs/paraview/src/ParaView-v5.0.1-source/VTK/Rendering/OpenGL2/vtkShaderProgram.cxx, > line 399 > vtkShaderProgram (0x42d9dc0): Shader object was not initialized, cannot > attach it. > > > Segmentation fault (core dumped) > ——— > > I found the following thread referring to such an issue: > http://vtk.1045678.n5.nabble.com/segfault-with-Opengl2-in-6-3-0-rc2-td5733742.html > But it seems to be not exactly the problem I am facing. > Another thing refers to EGL: > https://www.mail-archive.com/paraview@paraview.org/msg25773.html, which > again seems to be not really the > same problem. > > This problem already arose in 5.0.0, but persists in 5.0.1. With the > legacy rendering backend paraview continues to work in my setup. > > Can anybody give me some hints on how to investigate this further, or is > there already a solution? > > Thanks a lot, > Harald > ___ > 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 > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] eyedomelightning in paraview 5?
The Eye Dome Lighting code has been added to newer versions of VTK (as a render pass in OpenGL2) so in the future we should not need a plugin for it. Right now I think it is a matter of exposing it in the PV gui somehow when PV is built with OpenGL2. Ken On Wed, Apr 6, 2016 at 1:52 PM, Thomas Engels via ParaView < paraview@paraview.org> wrote: > Hello, > > I used to use the EyeDomeLightning plugin ( see > e.g.,https://blog.kitware.com/eye-dome-lighting-a-non-photorealistic-shading-technique/ > ) > However, support for it seems to be dropped in the newest paraview > versions (>5.0). > Is it planned to re-include the plugin? Can it somehow still be used? > I found it a very helpful tool to create appealing visualizations. > > Best regards > Thomas Engels > > -- > Thomas Engels, Ph.D. > Postdoctoral Researcher > AIFIT Project (Flying insects in turbulence) > > Institut für Strömungsmechanik und Technische Akustik > FG Numerische Fluiddynamik (MB123) > Müller-Breslau-Strasse 8 > 10623 Berlin > Germany+49 30 314 22849 > > École normale supérieure > Laboratoire de Météorologie Dynamique > 24, Rue Lhomond > 75231 Paris Cedex 05 > France > > > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] libGL error: failed to load driver: swrast
Someone else here may know better, but on Linux I believe it is not so much paraview as making sure you have the right OpenGL implementation. It might be a matter of grabbing a newer version of Mesa (provides OpenGL) using apt get or something like that. Push comes to shove you can build mesa yourself ala http://www.mesa3d.org/llvmpipe.html Someone more familiar with Linux/Mesa may be able to give you better specifics. On Mon, Mar 21, 2016 at 11:09 AM, Rob Nagler <paraview-vx...@q33.us> wrote: > Thanks, Ken. I am very new to ParaView. How do I tell ParaViewWeb to use > llvmpipe? > > Rob > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] libGL error: failed to load driver: swrast
For software rasterization in Mesa I think llvmpipe is the safer bet. If I
recall correctly swrast is an old legacy rasterizer and does not support
the more modern OpenGL functions in Mesa.
Ken
On Mon, Mar 21, 2016 at 10:49 AM, Rob Nagler <paraview-vx...@q33.us> wrote:
> I'm trying to install and run ParaViewWeb. I've tried: Fedora 21, Debian
> Jessie, & Ubuntu 14.0.4 and ParaView 4.1 (pvw-setup, stock pkgs, bin/src
> download) and 5.0 on each. None work, and they fail for different reasons.
> Here's one failure on Ubuntu 14.0.4 with
> ParaView-5.0.0-Qt4-OpenGL2-MPI-Linux-64bit.tar.gz:
>
> $ ./bin/pvpython
> lib/paraview-5.0/site-packages/paraview/web/pv_web_visualizer.py --content
> ./share/paraview-5.0/www --data-dir ~/tmp --port 8080
> 2016-03-20 15:28:46+ [-] Log opened.
> libGL error: failed to load driver: swrast
> X Error of failed request: GLXBadFBConfig
> Major opcode of failed request: 150 (GLX)
> Minor opcode of failed request: 34 ()
> Serial number of failed request: 29
>
> The swrast driver seems to be there:
>
> $ find /usr -name \*swrast\*
> /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
> /usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_swrast.so
>
> Running strace shows that it does load
> /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so and fails later with this, I
> think:
>
> close(4)= 0
> open("/home/vagrant/.drirc", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> munmap(0x7f0439de2000, 5648480) = 0
> write(2, "libGL error: ", 13libGL error: ) = 13
> write(2, "failed to load driver: swrast\n", 30failed to load driver: swrast
>
> More of the strace found here: http://pastebin.com/krQ5ZR4J
>
> Even if I create ~/.drirc it still gets the same error without any clear
> reason why.
>
> Thanks,
> Rob
>
> ___
> 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
>
>
--
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971
This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee. Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message. Thank you.
___
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
Re: [Paraview] CellDataToPointData much slower in 5.0?
Pulled this off list since I have some ignorant questions to ask :-) So I loaded the data and it seems to render fine (100 fps). I did not have the state file so I'm not sure what pipeline etc is being used. When I hit the animation button it plugs along at one frame a second or so. I have no clue if that is what is expected or not. It appears that the rendering data is being rebuilt every frame. Again I just don't know enough about PV to know if that is expected or not. I would think PV would cache the timesteps if the size is modest but maybe not. I will build PV and run it in the profiler but it may be tomorrow before the build wraps up. If you have a modest VTK example then I could probably answer your question easily.But PV is a much more complex beast and I do not know the internals well enough to guess. Thanks Ken On Tue, Feb 23, 2016 at 10:46 AM, Joachim Pouderoux < joachim.pouder...@kitware.com> wrote: > Wow, this is indeed very slow. > Looking at the Timer Log it seems to me like what is slow is the rendering. > Indeed: add an Outline filter after the CellDataToPointData and hide the > CellDataToPointData source. It's fast as it should. You can also try with a > ProgrammableFilter, same result. > > It looks like what is slow is coloring by a PointData array (choose a > celldata array and is fast)... > > @Ken: any idea why this happens? is it something that has been fixed > recently? > > Joachim > > > *Joachim Pouderoux* > > *PhD, Technical Expert* > *Kitware SAS <http://www.kitware.fr>* > > > 2016-02-23 16:25 GMT+01:00 Ruggiero Guida <ruggiero.gu...@gmail.com>: > >> The pipeline has been generated with 4.4 though. >> >> On Tue, 23 Feb 2016 at 15:24 Ruggiero Guida <ruggiero.gu...@gmail.com> >> wrote: >> >>> Hi Joachim, >>> >>> You can download the first 10 files of the series here >>> <https://dl.dropboxusercontent.com/u/1342856/Archive.zip>. I am also >>> attaching the state file >>> >>> The pipeline is quite simple: >>> - Open files >>> - Apply filter >>> >>> Thanks >>> Ruggiero >>> >>> On Tue, 23 Feb 2016 at 15:09 Joachim Pouderoux < >>> joachim.pouder...@kitware.com> wrote: >>> >>>> Ruggiero, >>>> >>>> Could you give us the whole pipeline involved here? >>>> As you are processing temporal data, CellDataToPointData might not be >>>> the problem here: the reader might be the cause. >>>> >>>> Joachim >>>> >>>> *Joachim Pouderoux* >>>> >>>> *PhD, Technical Expert* >>>> *Kitware SAS <http://www.kitware.fr>* >>>> >>>> >>>> 2016-02-23 15:16 GMT+01:00 Ruggiero Guida <ruggiero.gu...@gmail.com>: >>>> >>>>> Hi Cory, >>>>> >>>>> I am using the binary version: >>>>> >>>>> ParaView-5.0.0-Qt4-OpenGL2-MPI-OSX10.7-64bit.dmg >>>>> >>>>> Thanks >>>>> Ruggiero >>>>> >>>>> On Tue, 23 Feb 2016 at 14:15 Cory Quammen <cory.quam...@kitware.com> >>>>> wrote: >>>>> >>>>>> Ruggiero, >>>>>> >>>>>> Are you using the ParaView 5.0 MacOS binary from the ParaView >>>>>> downloads page, or are you building it yourself? If the latter, make >>>>>> sure to build in Release mode. >>>>>> >>>>>> Thanks, >>>>>> Cory >>>>>> >>>>>> On Tue, Feb 23, 2016 at 9:14 AM, Ruggiero Guida >>>>>> <ruggiero.gu...@gmail.com> wrote: >>>>>> > Hi, >>>>>> > >>>>>> > I am testing Paraview 5.0 on MacOS X Yosemite and I have noticed >>>>>> that the >>>>>> > CellDataToPointData filter has become very, very slow. >>>>>> > >>>>>> > I am visualizing a timeseries and each timestep may take up to 2 >>>>>> seconds to >>>>>> > be visualized. >>>>>> > >>>>>> > In order to verify I have reinstalled 4.4 and everything is smooth >>>>>> as >>>>>> > always. >>>>>> > >>>>>> > Any suggestion on why this is happening? Is there any default >>>>>> parameter that >>>>>> > I should set? >>>>>> > >>>>>> > Thanks >>>>
Re: [Paraview] [EXTERNAL] Paraview 5 crashes openning any chemiical format
For some reason I recall this issue as well. My PV build seemed to work while the installed PV binary crashed. Maybe somehow tied into the new DomainsChemestryOpenGL2 library that has the new specialized molecular mappers in it. Ken On Mon, Feb 15, 2016 at 4:44 PM, Scott, W Alan <wasc...@sandia.gov> wrote: > Do you have a dataset you could share? > > > > Alan > > > > *From:* ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of > *Henrique > C. S. Junior > *Sent:* Sunday, February 14, 2016 1:19 PM > *To:* paraview@paraview.org > *Subject:* [EXTERNAL] [Paraview] Paraview 5 crashes openning any > chemiical format > > > > Using Windows 10 64 bit any chemical format (XYZ, PDB or CML) causes a > crash in Paraview 5 (both openmpi or serial versions). > > Attached is a screenshot of the error. > > Is anyone facing a similar issue? > > > > > > -- > > *Henrique C. S. Junior* > Químico Industrial - UFRRJ > > Mestrando em Química Inorgânica - UFRRJ > Centro de Processamento de Dados - PMP > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView
Nice job Adam! I've though about your issue some more and I think the best solution is to revamp the vtkCompositePolyDataMapper2 to work a little differently. Basically always have it group together blocks that have the same properties and then render each of them with a helper mapper. That would give us great performance in both cases. I have added it to the OpenGL2 ToDo list just, not sure how soon someone will get to it as the old code works, it just isn't optimal in all cases. Thanks! Ken On Tue, Jan 5, 2016 at 12:39 PM, Adam Lyon <l...@fnal.gov> wrote: > Hi - Just thought I'd let you all know that I've finally made progress on > this problem. To recap, I have a MultiBlockDataSet (MBDS) containing > PolyData objects. The PolyData objects don't all have the same attributes > (some have Normals, some don't; some have particular FieldData, others > don't). This "heterogeneous" MBDS reflects the visualization data I get > from the Geant4 simulation program - some things have particular attributes > and others don't. > > As you (Ken & Utkarsh) pointed out, such a heterogenous MBDS triggers a > generic renderer in ParaView v5/OpenGL2 unless every block within the MBDS > has the same structure. The generic renderer is extremely slow, and it > makes interacting with the visualization in ParaView painful (e.g. a few > frames per second or less). > > I now have a filter (I should fix my ParaView Source that creates the MBDS > - but that'll be for later) that runs through the MBDS and makes it > homogeneous - that is it removes Normals and TCoords (only a very few > PolyData have them) and adds missing FieldData with defaults. This triggers > the fast renderer - and boy it's *a lot* faster. 30x - 200x faster frame > rates compared to the generic renderer. The fast renderer is at least many > times faster than the OpenGL1 renderer in ParaView v4.4. > > I'm quite happy with this solution and am glad I can finally use the new > features in ParaView v5/OpenGL2. Woohoo! > > I'm wondering if other people are going to hit this generic renderer > slowness.. I added some code to my build of ParaView v5 in > vtkCompositePolyDataMapper2.cxx that std::cout's a message when the generic > renderer is triggered and why (e.g. heterogeneous Normals, TCoords, > Scalars, etc). I found that to be very helpful. Perhaps the render > annotation could show such a message (e.g. in vtkPVRenderView). > > Thanks again for your help!! And Happy New Year!! -- Adam > > *--* > > *Adam L. Lyon* > *Scientist; Associate Division Head for Systems for Scientific > Applications* > > Scientific Computing Division & Muon g-2 Experiment > Fermi National Accelerator Laboratory > 630 840 5522 office > www.fnal.gov > l...@fnal.gov > > Connect with us! > Newsletter <http://www.fnal.gov/pub/today/> | Facebook > <https://www.facebook.com/Fermilab> | Twitter > <https://twitter.com/Fermilab> > > On Wed, Dec 16, 2015 at 1:46 PM, Ken Martin <ken.mar...@kitware.com> > wrote: > >> This code is all new hence the change. On the plus side if you moved from >> 4000 blocks of 10 triangles each to 4000 blocks of 1 triangles each the >> rendering performance would probably not slow down. The overhead is all in >> starting and stopping each of those 4000 mappers. >> >> The old backend wrote everything out into a displaylist and the OpenGL >> driver handled optimizing it and dealing with any inconsistencies. The new >> backend has to build vertex buffer objects and we currently only collapse >> all the blocks together into one VBO if the VBO structure is the same for >> every block. >> >> Thanks >> Ken >> >> >> On Wed, Dec 16, 2015 at 2:22 PM, Adam Lyon <l...@fnal.gov> wrote: >> >>> Hi Ken - thanks for your reply. It's looking like the last approach - I >>> figure out why I'm getting different blocks - is the way to go. It's >>> already clear that not all of the blocks have colors. Some of the blocks >>> are created by vtk sources (e.g. VtkConeSource) and others are created by >>> hand (me setting points and cells). The latter won't have normals. Maybe >>> some of the former do. I'll look into this. >>> >>> I'm curious as to why I didn't have any of these problems in v4.4 -- or >>> is this two path multiblock rendering code all new for v5? Thanks again!! >>> -- Adam >>> >>> *--* >>> >>> *Adam L. Lyon* >>> *Scientist; Associate Division Head for Systems for Scientific >>> Applications* >>> >>> Scientific Computing Division & Muon g-2 Experiment >>> Fermi Natio
Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView
This code is all new hence the change. On the plus side if you moved from 4000 blocks of 10 triangles each to 4000 blocks of 1 triangles each the rendering performance would probably not slow down. The overhead is all in starting and stopping each of those 4000 mappers. The old backend wrote everything out into a displaylist and the OpenGL driver handled optimizing it and dealing with any inconsistencies. The new backend has to build vertex buffer objects and we currently only collapse all the blocks together into one VBO if the VBO structure is the same for every block. Thanks Ken On Wed, Dec 16, 2015 at 2:22 PM, Adam Lyon <l...@fnal.gov> wrote: > Hi Ken - thanks for your reply. It's looking like the last approach - I > figure out why I'm getting different blocks - is the way to go. It's > already clear that not all of the blocks have colors. Some of the blocks > are created by vtk sources (e.g. VtkConeSource) and others are created by > hand (me setting points and cells). The latter won't have normals. Maybe > some of the former do. I'll look into this. > > I'm curious as to why I didn't have any of these problems in v4.4 -- or is > this two path multiblock rendering code all new for v5? Thanks again!! -- > Adam > > *--* > > *Adam L. Lyon* > *Scientist; Associate Division Head for Systems for Scientific > Applications* > > Scientific Computing Division & Muon g-2 Experiment > Fermi National Accelerator Laboratory > 630 840 5522 office > www.fnal.gov > l...@fnal.gov > > Connect with us! > Newsletter <http://www.fnal.gov/pub/today/> | Facebook > <https://www.facebook.com/Fermilab> | Twitter > <https://twitter.com/Fermilab> > > On Wed, Dec 16, 2015 at 11:47 AM, Ken Martin <ken.mar...@kitware.com> > wrote: > >> I don't really have a solution planned for that case. The data size is >> trivially small but it falls into the slow path because each block of data >> may or may not have normals or colors or tcoords. The nature of the blocks >> is heterogeneous. So you end up with 4000 mappers each rendering 10 >> triangles. Currently there are two paths for rendering multiblock data. >> >> 1) every block has the same properties (normals, tcoords, triangles) In >> that case we use a fast path, the actual values of course may be different, >> but if one block has texture coordinates then all of them will. >> >> 2) blocks can be different, meaning that one block may be triangles with >> normals while the next could be lines with texture coordinates. In that >> case we fall back on just giving each block its own mapper. That is the >> slow path. >> >> What would benefit your case is a third path (or a better slow path) >> where the blocks can be different, but we combine the ones that are the >> same so that hopefully we end up with maybe 4 or 5 mappers each with 1000 >> or so triangles. Implementing that is not trivial though so I don't think >> anyone has plans for it yet. >> >> Another approach would be to look at what is generating your data and try >> to determine why some blocks have normals while others do not. because if >> you can get the blocks to be homogeneous then you will get the fast path. >> >> Thanks >> Ken >> >> >> >> >> >> >> >> On Wed, Dec 16, 2015 at 11:39 AM, Adam Lyon <l...@fnal.gov> wrote: >> >>> Hi Ken and Utkarsh, Checking back in with this issue... I still find >>> that interaction with the g-2 ring in ParaView v5rc2 is very slow compared >>> to v4.4. It looks like you all have a solution in mind. I'm happy to build >>> from master to try it if the solution is there. Thanks again and Happy >>> Holidays!!! I really appreciate you all looking at this problem. -- Adam >>> >>> *--* >>> >>> *Adam L. Lyon* >>> *Scientist; Associate Division Head for Systems for Scientific >>> Applications* >>> >>> Scientific Computing Division & Muon g-2 Experiment >>> Fermi National Accelerator Laboratory >>> 630 840 5522 office >>> www.fnal.gov >>> l...@fnal.gov >>> >>> Connect with us! >>> Newsletter <http://www.fnal.gov/pub/today/> | Facebook >>> <https://www.facebook.com/Fermilab> | Twitter >>> <https://twitter.com/Fermilab> >>> >>> On Fri, Nov 20, 2015 at 1:48 PM, Ken Martin <ken.mar...@kitware.com> >>> wrote: >>> >>>> You could maybe have an actor per LOD and then swap actors in and out. >>>> >>>> Actor owns the property, backface property, an
Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView
I don't really have a solution planned for that case. The data size is trivially small but it falls into the slow path because each block of data may or may not have normals or colors or tcoords. The nature of the blocks is heterogeneous. So you end up with 4000 mappers each rendering 10 triangles. Currently there are two paths for rendering multiblock data. 1) every block has the same properties (normals, tcoords, triangles) In that case we use a fast path, the actual values of course may be different, but if one block has texture coordinates then all of them will. 2) blocks can be different, meaning that one block may be triangles with normals while the next could be lines with texture coordinates. In that case we fall back on just giving each block its own mapper. That is the slow path. What would benefit your case is a third path (or a better slow path) where the blocks can be different, but we combine the ones that are the same so that hopefully we end up with maybe 4 or 5 mappers each with 1000 or so triangles. Implementing that is not trivial though so I don't think anyone has plans for it yet. Another approach would be to look at what is generating your data and try to determine why some blocks have normals while others do not. because if you can get the blocks to be homogeneous then you will get the fast path. Thanks Ken On Wed, Dec 16, 2015 at 11:39 AM, Adam Lyon <l...@fnal.gov> wrote: > Hi Ken and Utkarsh, Checking back in with this issue... I still find that > interaction with the g-2 ring in ParaView v5rc2 is very slow compared to > v4.4. It looks like you all have a solution in mind. I'm happy to build > from master to try it if the solution is there. Thanks again and Happy > Holidays!!! I really appreciate you all looking at this problem. -- Adam > > *--* > > *Adam L. Lyon* > *Scientist; Associate Division Head for Systems for Scientific > Applications* > > Scientific Computing Division & Muon g-2 Experiment > Fermi National Accelerator Laboratory > 630 840 5522 office > www.fnal.gov > l...@fnal.gov > > Connect with us! > Newsletter <http://www.fnal.gov/pub/today/> | Facebook > <https://www.facebook.com/Fermilab> | Twitter > <https://twitter.com/Fermilab> > > On Fri, Nov 20, 2015 at 1:48 PM, Ken Martin <ken.mar...@kitware.com> > wrote: > >> You could maybe have an actor per LOD and then swap actors in and out. >> >> Actor owns the property, backface property, and texture. Changes to those >> objects can cause VBO/IBO rebuilds (switching from surface to wireframe, >> adding a texture map, flat versus phong shading, edge visibility, line >> width, etc.) The old backend only looked at the actor's property which is >> sort of broken. >> >> For example in the old backend: create two properties, one set to >> wireframe, one set to surface. Then create an actor and mapper set to use >> display lists. Switching between the two properties will cause an actor >> mtime change, but the properties themselves would still have low mtimes I >> believe. In that case the old backend will end up stuck in one >> representation because it only looks at the property mtime not actor. >> >> To make the VBO/IBO rebuild safely (but less often than currently) I >> think the solution is to check the mtimes as is done currently, if those >> are modified then collect up the parameters that require a VBO or IBO >> rebuild and compare them to a stored value from the last build. If >> different force a rebuild. That is the best solution IMO just takes some >> time. I sort of wanted to do that anyhow but now I can say you forced me >> into it :-) >> >> Thanks >> Ken >> >> >> >> >> On Fri, Nov 20, 2015 at 1:57 PM, Utkarsh Ayachit < >> utkarsh.ayac...@kitware.com> wrote: >> >>> > I did notice PV is forcing the actor to be modified every time the LOD >>> > changes (which is a lot). Modifying the actor causes the VBO/IBOs to >>> rebuild >>> > so it would be better not to do that unless you really need to and in >>> this >>> > case I'm not sure why it is being done. Specifically I think it is in >>> > vtkPVLODActor::Modified where it calls this->Device->Modified() . The >>> LOD >>> > actor is being modified as a result of calling SetEnableLOD constantly >>> > flipping between true and false. That is not the cause of this issue >>> but it >>> > is something I noticed that will be a pain for large datasets. >>> >>> Ken, currently, there's no way around it. vtkPVLODActor works by >>> changing the mapper on the internal vtkActor aka Devi
Re: [Paraview] Paraview v5.0.0-RC1 with OpenGL2 backend not running using OSMESA v10.5.5
Thanks Frank, This is an area we are actively working to cleanup right now. Both in catching it more gracefully and in providing better messages to help people understand what the next step should be. I believe if you are in an Intel based system that using their new SWR backend for mesa ( http://openswr.org/ ) might give the best software rendering performance. I think it requires a more recent version of Mesa, we suggest Mesa 10.6.5 or later for VTK. Other people on this list are more familiar with the specifics of setting up SWR and Mesa on a cluster but I wanted to at least give you a quick response to let you know we are working on it :-) Thanks Ken On Thu, Dec 10, 2015 at 8:47 AM, Albina, Frank < frank.alb...@sauber-motorsport.com> wrote: > Hi all! > > > > First of all, thanks for all the effort spent on porting the rendering > engine to support the OpenGL2 backend by default on PV 5.0.0. Early tests > with the binary from the download page shows a massive improvement over the > PV 4.1 to 4.3 versions in terms of rendering time. I have repeated the test > over a few different GPUs and got the same results. > > > > Which brought me to thinking that similar performance improvements could > be also achieved when performing software rendering with the MESA > libraries. I downloaded the PV sources for the 5.0.0-RC1 release yesterday > and compiled it with MESA and MPI support. MPI version is Intel 5.0.1 and > MESA version is 10.5.5. The MESA libraries are compiled using: > > > > ./configure --enable-64-bit --enable-texture-float --enable-osmesa > --disable-egl --disable-xorg --disable-xvmc --disable-opencl --disable-glx > --disable-dri --disable-va --disable-shared-glapi --enable-gallium-llvm=no > --with-gnu-ld --with-osmesa-bits=8 --disable-vdpau > --enable-dependency-tracking --with-gallium-drivers=”” > --with-dri-drivers=”” --with-egl-platforms=”” > > > > Which corresponds to a “classic” compilation without LLVM support. Believe > it or not, this was found to run faster on our CPU cluster than with the > LLVM drivers. > > > > After linking PV 5.0.0 against the MESA libs with the OpenGL2 backend, I > started running a simple benchmark to check possible performance benefits > and here is the error output I got: > > > > GL_Version: 2.1 Mesa 10.5.5 > > Warning: In > /panfs/srvpan01/code/repo/build/paraview-5.0.0-rc1/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, > line 549 > > vtkOSOpenGLRenderWindow (0x3c0eef60): VTK is designed to work with OpenGL > version 3.2 but it appears it has been given a context that does not > support 3.2. VTK will run in a compatibility mode designed to work with > OpenGL 2.1 but some features may not work. > > > > ERROR: In > /panfs/srvpan01/code/repo/build/paraview-5.0.0-rc1/src/VTK/Rendering/OpenGL2/vtkShaderProgram.cxx, > line 369 > > vtkShaderProgram (0x4d4dbfe0): 1: #version 120 > > 2: #extension GL_EXT_gpu_shader4 : require > > 3: #define highp > > 4: #define mediump > > 5: #define lowp > > 6: > > 7: > /*= > > 8: > > 9: Program: Visualization Toolkit > > 10: Module:vtkPolyDataFS.glsl > > 11: > > 12: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen > > 13: All rights reserved. > > 14: See Copyright.txt or http://www.kitware.com/Copyright.htm for > details. > > 15: > > 16: This software is distributed WITHOUT ANY WARRANTY; without even > > 17: the implied warranty of MERCHANTABILITY or FITNESS FOR A > PARTICULAR > > 18: PURPOSE. See the above copyright notice for more information. > > 19: > > 20: > =*/ > > 21: // Template for the polydata mappers fragment shader > > 22: > > 23: uniform int PrimitiveIDOffset; > > 24: > > 25: // VC position of this fragment > > 26: varying vec4 vertexVCVSOutput; > > 27: > > 28: // optional color passed in from the vertex shader, vertexColor > > 29: uniform bool OverridesColor; > > 30: uniform float opacityUniform; // the fragment opacity > > 31: uniform vec3 ambientColorUniform; // intensity weighted color > > 32: uniform vec3 diffuseColorUniform; // intensity weighted color > > 33: uniform vec3 specularColorUniform; // intensity weighted color > > 34: uniform float specularPowerUniform; > > 35: > > 36: > > 37: // optional surface normal declaration > > 38: uniform int cameraParallel; > > 39: > > 40: // extra lighting parameters > > 41: uniform int numberOfLights; > > 42: uniform vec3 lightColor[6]; > &g
Re: [Paraview] OpenGL Backend Identification
w this link to subscribe/unsubscribe: > >>>> http://public.kitware.com/mailman/listinfo/paraview > >>> > >>> > >> > >> > >> ___ > >> 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 > >> > > > > > > ___ > > 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 > > > ___ > 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 > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView
You could maybe have an actor per LOD and then swap actors in and out. Actor owns the property, backface property, and texture. Changes to those objects can cause VBO/IBO rebuilds (switching from surface to wireframe, adding a texture map, flat versus phong shading, edge visibility, line width, etc.) The old backend only looked at the actor's property which is sort of broken. For example in the old backend: create two properties, one set to wireframe, one set to surface. Then create an actor and mapper set to use display lists. Switching between the two properties will cause an actor mtime change, but the properties themselves would still have low mtimes I believe. In that case the old backend will end up stuck in one representation because it only looks at the property mtime not actor. To make the VBO/IBO rebuild safely (but less often than currently) I think the solution is to check the mtimes as is done currently, if those are modified then collect up the parameters that require a VBO or IBO rebuild and compare them to a stored value from the last build. If different force a rebuild. That is the best solution IMO just takes some time. I sort of wanted to do that anyhow but now I can say you forced me into it :-) Thanks Ken On Fri, Nov 20, 2015 at 1:57 PM, Utkarsh Ayachit < utkarsh.ayac...@kitware.com> wrote: > > I did notice PV is forcing the actor to be modified every time the LOD > > changes (which is a lot). Modifying the actor causes the VBO/IBOs to > rebuild > > so it would be better not to do that unless you really need to and in > this > > case I'm not sure why it is being done. Specifically I think it is in > > vtkPVLODActor::Modified where it calls this->Device->Modified() . The LOD > > actor is being modified as a result of calling SetEnableLOD constantly > > flipping between true and false. That is not the cause of this issue but > it > > is something I noticed that will be a pain for large datasets. > > Ken, currently, there's no way around it. vtkPVLODActor works by > changing the mapper on the internal vtkActor aka Device when LOD mode > is toggled. That will indeed change the Device's MTime even if we stop > calling this->Device->Modiied() in the vtkPVLODActor::Modified(). The > question is why are VBO/IBOs rebuild if actor MTime changes? VBOs > would be data dependent right? Most of data-dependent properties are > on the Mapper, not the actor. Shouldn't the code that re-creates > VBO/IBOs only depend on Mapper's MTime? > > Utkarsh > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView
I took a quick look at it. I see everything from 16 to 111 fps on my laptop which is a pretty wild range of numbers. I'll do a release build with OpenGL1 to see what that shows but it will take a while. This dataset is using the slow path because it has some blocks that have normals and some that do not. Same idea for tcoords. I did notice PV is forcing the actor to be modified every time the LOD changes (which is a lot). Modifying the actor causes the VBO/IBOs to rebuild so it would be better not to do that unless you really need to and in this case I'm not sure why it is being done. Specifically I think it is in vtkPVLODActor::Modified where it calls this->Device->Modified() . The LOD actor is being modified as a result of calling SetEnableLOD constantly flipping between true and false. That is not the cause of this issue but it is something I noticed that will be a pain for large datasets. Thanks Ken On Thu, Nov 19, 2015 at 9:05 AM, Utkarsh Ayachit < utkarsh.ayac...@kitware.com> wrote: > Yes, I am noticing that slowness too. Ken, mind taking a look at that? > > Utkarsh > > > > On Nov 19, 2015, at 12:38 AM, Adam Lyon <l...@fnal.gov> wrote: > > Indeed you are right! I see the rendering you show for 5.0. Interesting > change with regard to setting the solid color first. > > One thing I should note is that image manipulation (pan, zoom, rotate) is > quite slow in 5.0 compared to 4.4. For example, rotating the ring with a > solid color, I get frame-rates (from the annotation text) of over 100 fps > with 4.4. With 5.0 I generally see about 20-25fps. Do you see this too? > Thanks again!! -- Adam > > *--* > > *Adam L. Lyon* > *Scientist; Associate Division Head for Systems for Scientific > Applications* > > Scientific Computing Division & Muon g-2 Experiment > Fermi National Accelerator Laboratory > 630 840 5522 office > www.fnal.gov > l...@fnal.gov > > Connect with us! > Newsletter <http://www.fnal.gov/pub/today/> | Facebook > <https://www.facebook.com/Fermilab> | Twitter > <https://twitter.com/Fermilab> > > On Tue, Nov 17, 2015 at 4:44 PM, Utkarsh Ayachit < > utkarsh.ayac...@kitware.com> wrote: > >> Ken, what Adam has is a multiblock dataset with field data array named >> "Color" (with certain blocks missing this array). Now when you color by >> this array and then uncheck "Map Scalars", I get the attached images. I'd >> contend that 5.0 with OpenGL2 rendering is correct. In 4.4 it would just >> bleed some random color through for blocks with missing "Color" array. In >> 5.0, the color used is the "Solid Color" set before changing the array to >> color with. >> >> Adam, are you not seeing rendering as I am with 5.0? I no longer get >> rendering similar to the images you reported. >> >> Utkarsh >> >> >> > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] ParaView 5.0.0-RC1 is missing PointSprite Rendering Plugin
The OpenGL2 backend includes the vtkPointGaussianMapper which can render colored points, guassian splats, and more complex options when you specify your own shader code. Take a look at the code in VTK/Rendering/OpenGL2/Testing/Cxx/TestPoint* to see some of what you can do. Most of these feature are also available in PV through the use of the PointGaussian plugin. Load that plugin before loading your points and then it should show up as an option for the representation. Thanks Ken On Wed, Nov 18, 2015 at 8:57 AM, Christian Richter < christian.rich...@ovgu.de> wrote: > The precompiled binaries does not contain the PointSprite Rendering > Plugin. It seems it is not compatible with the openGL2 rendering engine. > When I compile from source it works with opengl only. > Is there a plan to support PointSprites in final release version ? > Also there is still a bug since PV 4.2.0 that the Radius and Opacity > Editor does not respect the selected "Scale by" data-array for the scalar > range (it did until 4.1.0) so the user needs to set it by hand which is > really annoying when one needs to scale by radius. > http://www.paraview.org/Bug/view.php?id=15017 > > Best, > Christian Richter > > Am 11/12/2015 um 9:45 PM schrieb Ben Boeckel: > >> Folks, >> >> ParaView 5.0.0-RC1 is now available for download. Checkout the release >> notes on the Kitware blog [1]. >> >> As always, we look forward to your feedback [2]. >> >> Also stay tuned to the Kitware Blog [3] for upcoming features and >> enhancements to ParaView, ParaView Catalyst, ParaViewWeb and much >> more! >> >> - The ParaView team >> >> [1] http://kitware.com/blog/home/post/998 >> [2] http://paraview.uservoice.com >> [3] http://www.kitware.com/blog/ >> ___ >> 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 >> > > ___ > 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 > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView
Yes, thank goodness, I thought this dataset looked familiar. Now I remember looking into this a while back and yes, the decision we landed on was as you specified. The new code is different from the old version, but to me a much safer and better approach. If the data is missing for a block we use the solid color, not whatever the last used color happened to be from the preceding block. Hopefully that explains it (fingers crossed). Thanks Ken On Tue, Nov 17, 2015 at 5:44 PM, Utkarsh Ayachit < utkarsh.ayac...@kitware.com> wrote: > Ken, what Adam has is a multiblock dataset with field data array named > "Color" (with certain blocks missing this array). Now when you color by > this array and then uncheck "Map Scalars", I get the attached images. I'd > contend that 5.0 with OpenGL2 rendering is correct. In 4.4 it would just > bleed some random color through for blocks with missing "Color" array. In > 5.0, the color used is the "Solid Color" set before changing the array to > color with. > > Adam, are you not seeing rendering as I am with 5.0? I no longer get > rendering similar to the images you reported. > > Utkarsh > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView
gt;>>> *Joachim Pouderoux* >>>>> >>>>> *PhD, Technical Expert* >>>>> *Kitware SAS <http://www.kitware.fr>* >>>>> >>>>> >>>>> 2015-07-30 22:19 GMT+02:00 Adam Lyon <l...@fnal.gov>: >>>>> >>>>>> Hi, I'm trying to use ParaView built with OpenGL2, hoping to see >>>>>> some speed improvement when I interact with my visualization. Indeed for >>>>>> a >>>>>> complicated geometry I see significant speed up (e.g. ~25 fps with >>>>>> OpenGL2 >>>>>> vs. 5 fps with regular ParaView). But I also see serious errors in the >>>>>> display. I've attached two images of our "g-2 muon storage ring" (never >>>>>> mind what it actually is, though it is very cool :-) .. >>>>>> >>>>>> [image: Inline image 1] >>>>>> >>>>>> The first, mostly blue image, is from regular ParaView (downloaded >>>>>> Mac binary 4.3.1 64 bit) and is what the ring is supposed to look like. >>>>>> There is a color vector selected and I've unchecked "Map scalars" so that >>>>>> the colors are "true". And indeed the RGB color values in the vector are >>>>>> what is shown on the display. >>>>>> >>>>>> >>>>>> [image: Inline image 2] >>>>>> The next image, with a chunk on the left side missing, is from the >>>>>> OpenGL2 ParaView (Mac built from source 4.3.1-882-gbdceec7 64 bit) >>>>>> configured identically as the other ParaView. So it should look identical >>>>>> to the mostly blue picture. Along with the missing chunk, you see the >>>>>> colors look very wrong. What's even stranger is that the missing chunk is >>>>>> really missing - not invisible - the visualization is made of multiblock >>>>>> datasets, and right clicking where a structure should be only brings up >>>>>> the >>>>>> link camera option. >>>>>> >>>>>> You can try this yourself -- see >>>>>> https://www.dropbox.com/sh/900ocfc90v0w3r6/AACmqz8kVrGPUMnJbpxAFOzBa?dl=0 >>>>>> . The "gm2ring.zip" file has gm2ring.vtm (with the corresponding gm2ring >>>>>> directory) and gm2ring.pvsm to restore my configuration. >>>>>> >>>>>> I'm looking forward to using the OpenGL2 version when it works >>>>>> better. I hope this helps in working out its kinks (or hoping to find out >>>>>> I've built or configured something incorrectly). Let me know how I can >>>>>> help! Thanks! -- Adam >>>>>> *--* >>>>>> >>>>>> *Adam L. Lyon* >>>>>> *Scientist; Associate Division Head for Systems for Scientific >>>>>> Applications* >>>>>> >>>>>> Scientific Computing Division & Muon g-2 Experiment >>>>>> Fermi National Accelerator Laboratory >>>>>> 630 840 5522 office >>>>>> www.fnal.gov >>>>>> l...@fnal.gov >>>>>> >>>>>> Connect with us! >>>>>> Newsletter <http://www.fnal.gov/pub/today/> | Facebook >>>>>> <https://www.facebook.com/Fermilab> | Twitter >>>>>> <https://twitter.com/Fermilab> >>>>>> >>>>>> ___ >>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>> >>> ___ >>> 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 >>> >>> >> > > ___ > 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 > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. ___ 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
Re: [Paraview] Volume Rendering 17GB 8.5 billion cell volume
I just realized you are on PV 4.3.1, that version is probably old enough that we did not have OpenGL2 working with Mesa back then. Updating to a more recent PV/VTK will be needed to use OpenGL2 with Mesa (I think we got it working three or four months ago). As far as I know the 10.6 versions of Mesa should also work fine, anything after 10.5.4 should be good. Sorry for the confusion Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.mar...@kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* David Trudgian [mailto:david.trudg...@utsouthwestern.edu] *Sent:* Tuesday, September 15, 2015 12:43 PM *To:* Ken Martin; paraview@paraview.org *Subject:* RE: [Paraview] Volume Rendering 17GB 8.5 billion cell volume Am currently using Mesa 10.5.4 as I’d seen that as a working config mentioned somewhere on the web, so will try newer. Any reason to avoid the 10.6 series? I guess I should also try moving to Paraview 4.4 now :-) -- David Trudgian Ph.D. Computational Scientist, BioHPC UT Southwestern Medical Center Dallas, TX 75390-9039 Tel: (214) 648-4833 *From:* Ken Martin [mailto:ken.mar...@kitware.com <ken.mar...@kitware.com>] *Sent:* Monday, September 14, 2015 2:29 PM *To:* paraview@paraview.org *Subject:* Re: [Paraview] Volume Rendering 17GB 8.5 billion cell volume I am not sure about the rest of the email, but the error you included is typically caused by using too old of a version of mesa. I’m not sure about specific driver/etc but I usually suggest trying Mesa version 10.5.5 or later to see if that solves the issue. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.mar...@kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. From: *David Trudgian* <david.trudg...@utsouthwestern.edu> Date: Mon, Sep 14, 2015 at 1:35 PM Subject: RE: [Paraview] Volume Rendering 17GB 8.5 billion cell volume To: Aashish Chaudhary <aashish.chaudh...@kitware.com> Cc: Berk Geveci <berk.gev...@kitware.com>, ParaView list < paraview@paraview.org> I've now had chance to build paraview 4.3.1 with the OpenGL2 backend. I've not been able to test on GPU accelerated nodes (cluster is too busy to get enough right now), but I have also built as an OSMESA with OpenGL2 version. Unfortunately the symptoms are the same. With the largest 16GB VTI I see wireframe etc, but switching to volume rendering results in nothing visible in the client. No messages from the server or client. Memory usage well below RAM in the systems. Runnning across 8 256GB 24-core nodes with 8-mpi tasks per node. As with the OpenGL backend I go to our 9GB or 4GB downsampled VTIs and things work as expected. Great rendering performance running across the 8-node allocation with OpenMPI and OSMESA. I did also come across another issue. Switching back to surface view on the 16GB data I had a crash shortly after I started manipulating the view with the mouse. I couldn't replicate this crash with the smaller datasets though. ERROR: In /home2/dtrudgian/paraview/ParaView-v4.3.1-source/VTK/Rendering/OpenGL2/vtkShaderProgram.cxx, line 292 vtkShaderProgram (0x6488a60): 0:22(12): warning: extension `GL_EXT_gpu_shader4' unsupported in fragment shader 0:130(12): error: `gl_PrimitiveID' undeclared 0:130(12): error: operands to arithmetic operators must be numeric 0:130(12): error: operands to arithmetic operators must be numeric 0:131(28): error: operator '%' is reserved in GLSL 1.10 (GLSL 1.30 or GLSL ES 3.00 required) 0:131(22): error: cannot construct `float' from a non-numeric data type 0:131(22): error: operands to arithmetic operators must be numeric 0:131(17): error: cannot construct `vec4' from a non-numeric data type Cheers, -- David Trudgian Ph.D. Computational Scientist, BioHPC UT Southwestern Medical Center Dallas, TX 75390-9039 Tel: (214) 648-4833 -Original Message- From: David Trudgian Sent: Thursday, September 10, 2015 10:13 AM To: Aashish Chaudhary <aashish.chaudh.
Re: [Paraview] Volume Rendering 17GB 8.5 billion cell volume
I am not sure about the rest of the email, but the error you included is typically caused by using too old of a version of mesa. I’m not sure about specific driver/etc but I usually suggest trying Mesa version 10.5.5 or later to see if that solves the issue. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.mar...@kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. From: *David Trudgian* <david.trudg...@utsouthwestern.edu> Date: Mon, Sep 14, 2015 at 1:35 PM Subject: RE: [Paraview] Volume Rendering 17GB 8.5 billion cell volume To: Aashish Chaudhary <aashish.chaudh...@kitware.com> Cc: Berk Geveci <berk.gev...@kitware.com>, ParaView list < paraview@paraview.org> I've now had chance to build paraview 4.3.1 with the OpenGL2 backend. I've not been able to test on GPU accelerated nodes (cluster is too busy to get enough right now), but I have also built as an OSMESA with OpenGL2 version. Unfortunately the symptoms are the same. With the largest 16GB VTI I see wireframe etc, but switching to volume rendering results in nothing visible in the client. No messages from the server or client. Memory usage well below RAM in the systems. Runnning across 8 256GB 24-core nodes with 8-mpi tasks per node. As with the OpenGL backend I go to our 9GB or 4GB downsampled VTIs and things work as expected. Great rendering performance running across the 8-node allocation with OpenMPI and OSMESA. I did also come across another issue. Switching back to surface view on the 16GB data I had a crash shortly after I started manipulating the view with the mouse. I couldn't replicate this crash with the smaller datasets though. ERROR: In /home2/dtrudgian/paraview/ParaView-v4.3.1-source/VTK/Rendering/OpenGL2/vtkShaderProgram.cxx, line 292 vtkShaderProgram (0x6488a60): 0:22(12): warning: extension `GL_EXT_gpu_shader4' unsupported in fragment shader 0:130(12): error: `gl_PrimitiveID' undeclared 0:130(12): error: operands to arithmetic operators must be numeric 0:130(12): error: operands to arithmetic operators must be numeric 0:131(28): error: operator '%' is reserved in GLSL 1.10 (GLSL 1.30 or GLSL ES 3.00 required) 0:131(22): error: cannot construct `float' from a non-numeric data type 0:131(22): error: operands to arithmetic operators must be numeric 0:131(17): error: cannot construct `vec4' from a non-numeric data type Cheers, -- David Trudgian Ph.D. Computational Scientist, BioHPC UT Southwestern Medical Center Dallas, TX 75390-9039 Tel: (214) 648-4833 -Original Message- From: David Trudgian Sent: Thursday, September 10, 2015 10:13 AM To: Aashish Chaudhary <aashish.chaudh...@kitware.com> Cc: Berk Geveci <berk.gev...@kitware.com>; ParaView list < paraview@paraview.org> Subject: RE: [Paraview] Volume Rendering 17GB 8.5 billion cell volume Aashish, (sorry - didn't hit reply-all first time) > Would it be possible for you to try OpenGL2 backend? Yes - I can try this, but probably next week. I just change VTK_RENDERING_BACKENDS? Do you know if OSMESA has to be built with any particularly flags itself? Thanks, DT From: Aashish Chaudhary [aashish.chaudh...@kitware.com] Sent: Thursday, September 10, 2015 9:59 AM To: David Trudgian Cc: Berk Geveci; ParaView list Subject: Re: [Paraview] Volume Rendering 17GB 8.5 billion cell volume Thanks Dave. Haven' t looked at your email in detail (will do in a moment) but another thought would be some sort of limit we are hitting on the indices (MAX_INT or MAX_) being used when dealing with very large dataset such as yours. Would it be possible for you to try OpenGL2 backend? - Aashish On Thu, Sep 10, 2015 at 10:55 AM, David Trudgian < david.trudg...@utsouthwestern.edu<mailto:david.trudg...@utsouthwestern.edu>> wrote: Berk (and others), thanks for your replies! > This is pretty awesome. I am assuming that this has something to do > with things not fitting on the GPU memory or exceeding some texture > memory limitation. Can you provide some more details? Sure - thanks for your help. > * Which version of ParaView are you using? This is with Paraview 4.3.1 > * It sounds like you have multiple GPUs and multiple nodes. What is > the setup? Are you running in parallel with MPI? Have tried in two ways, both are using MPI (OpenMPI/1.8.3 on an InfiniBand FDR network): Setup 1) Paraview 4.3.1 pvserver is running with MPI across multiple cluster no
