Re: [Paraview] Optimus and Windows 10
Thanks, good to know. We'll try 5.2 (qt4) if the issue surfaces again,
Paul
On 05-12-17 14:13, Aron Helser wrote:
Yes, that Intel driver bug is known to affect ParaView:
https://gitlab.kitware.com/paraview/paraview/issues/17499
Regards,
Aron
On Tue, Dec 5, 2017 at 6:40 AM, Jonathan Borduas
<jonathan.bord...@caboma.com <mailto:jonathan.bord...@caboma.com>> wrote:
Was the laptop running with the intel gpu ? If so, it might be
related to an Intel driver bug that was reported on the QT and Intel
websites.
https://bugreports.qt.io/browse/QTBUG-40485
<https://bugreports.qt.io/browse/QTBUG-40485>
https://software.intel.com/en-us/node/744153
<https://software.intel.com/en-us/node/744153>
Jonathan Borduas
_____
From: Paul Melis <paul.me...@surfsara.nl
<mailto:paul.me...@surfsara.nl>>
Sent: Tuesday, December 5, 2017 04:16
Subject: [Paraview] Optimus and Windows 10
To: <paraview@paraview.org <mailto:paraview@paraview.org>>
Hi,
In our paraview course two weeks ago we had a student that had trouble
running Paraview 5.4.1 (official windows 64-bit binaries) under windows
10. The symptoms were that the main menu bar was invisible and that the
mouse cursor did not match up with the position of the click event,
making it very hard to do anything. It seemed the menu bar somehow had
shifted under the window title bar, causing the misalignment.
As this laptop was an optimus system we figured it might have something
to do with that. After some fiddling we found that right-clicking on
paraview.exe and picking Run with graphics processor ->
High-performance
NVIDIA processor solved the problem.
Is this a known issue?
Regards,
Paul
--
Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | paul.me...@surfsara.nl
<mailto:paul.me...@surfsara.nl> | www.surfsara.nl
<http://www.surfsara.nl> |
___
Powered by www.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
<http://www.kitware.com/opensource/opensource.html>
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView <http://paraview.org/Wiki/ParaView>
Search the list archives at: http://markmail.org/search/?q=ParaView
<http://markmail.org/search/?q=ParaView>
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
<http://public.kitware.com/mailman/listinfo/paraview>
___
Powered by www.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
<http://www.kitware.com/opensource/opensource.html>
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView <http://paraview.org/Wiki/ParaView>
Search the list archives at: http://markmail.org/search/?q=ParaView
<http://markmail.org/search/?q=ParaView>
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
<http://public.kitware.com/mailman/listinfo/paraview>
--
Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl |
___
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] Optimus and Windows 10
Hi, In our paraview course two weeks ago we had a student that had trouble running Paraview 5.4.1 (official windows 64-bit binaries) under windows 10. The symptoms were that the main menu bar was invisible and that the mouse cursor did not match up with the position of the click event, making it very hard to do anything. It seemed the menu bar somehow had shifted under the window title bar, causing the misalignment. As this laptop was an optimus system we figured it might have something to do with that. After some fiddling we found that right-clicking on paraview.exe and picking Run with graphics processor -> High-performance NVIDIA processor solved the problem. Is this a known issue? Regards, Paul -- Paul Melis | Visualization group leader & developer | SURFsara | | Science Park 140 | 1098 XG Amsterdam | | T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl | ___ 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] Client-server mode fails with 5.0.1
Hi Utkarsh, On 28-06-16 16:29, Utkarsh Ayachit wrote: As soon as I set the threshold to 0 the warning about the OpenGL 3.2 context pops up (but no segfault in this case). No segfault just means that the scene didn't attempt to rendering something that needed newer OpenGL. I tried a very minimal example that creates a 3.2 context (using SDL) and that fails as well, so maybe something strange is going in with our nvidia driver installation. I'll see if I can do some more tests. Cool. Thanks. I did some further testing, but can't find anything obviously wrong with our setup w.r.t OpenGL versions. I do notice that window setup in SDL2 fails due to the XRandR support finding no outputs configured on the graphics cards (there's nothing connected as these are cluster nodes). GLFW3 reports "X11: RandR monitor support seems broken", but initializes and renders (on :0.0) anyway when requesting a 3.2 context. Does ParaView, or VTK, use XRandR to get a valid window on which an OpenGL context is created? Could this be a reason I see the 3.2 context creation failure? Regards, Paul -- Paul Melis | Visualization group leader & developer | SURFsara | | Science Park 140 | 1098 XG Amsterdam | | T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl | ___ 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] A Potential Bug About Glyph (Paraview 5.1.0)
I got bitten by the default masking settings a couple of times as well. Maybe change the default to not do masking when the number of input points is low, like 1? Paul On 06/29/2016 12:23 AM, Scott, W Alan wrote: Huangrui Mo, Try outputting a glyph every point. On the Properties tab, under Masking, Glyph Mode, change this to off. Alan *From:*ParaView [mailto:paraview-boun...@paraview.org] *On Behalf Of *Huangrui Mo *Sent:* Tuesday, June 28, 2016 3:48 PM *To:* paraview@paraview.org *Subject:* [EXTERNAL] [Paraview] A Potential Bug About Glyph (Paraview 5.1.0) Dear Paraview Developer, When using the Glyph function to rend point sets, it may skip some points, as shown below This happens either in steady case or a unsteady case. In the latter, Glyph works at first and then disappear afterward. The .vtp file for generating the above point set has been attached in this email. Thank you very much for taking time to read this email. Sincerely, Huangrui Mo ___ 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
Re: [Paraview] [EXTERNAL] Client-server mode fails with 5.0.1
Hi Utkarsh, On 06/27/2016 07:15 PM, Utkarsh Ayachit wrote: Paul, Can you try this: 1. Connect to pvserver started with --use-offscreen-rendering 2. From Edit | Settings, Render View tab, set "Remote Render Threshold" to 0. Accept the change using OK. As soon as I set the threshold to 0 the warning about the OpenGL 3.2 context pops up (but no segfault in this case). I tried a very minimal example that creates a 3.2 context (using SDL) and that fails as well, so maybe something strange is going in with our nvidia driver installation. I'll see if I can do some more tests. Paul 3. Interact with render view. Do you get the same segfault? If so, it's independent of what you're rendering, but just the fact that remote rendering kicks in. We can then debug further. Utkarsh On Mon, Jun 27, 2016 at 11:37 AM, Paul Melis <paul.me...@surfsara.nl> wrote: On 06/27/2016 05:29 PM, Paul Melis wrote: On 04/19/2016 01:04 PM, Paul Melis wrote: Hi Utkarsh, On 18-04-16 20:04, Utkarsh Ayachit wrote: This has always worked for me with earlier versions of ParaView, but something seems to have changed. It could be the newer NVidia driver we use since a few weeks, but like I said, I don't see issues with any other OpenGL application. Paul, can you try with ParaView 5.0.0 and 4.4 binaries as well? Since those worked before, let's see if it's a NVIdia driver change that's affecting ParaView. 4.4 works without problem in client-server mode (although I can't seem to get subsampled rendering during interaction working, no matter what remote render settings I try). 5.0.0 shows the same GLX-related issue as 5.0.1. It smells like an interaction between the new OpenGL2 backend and the NVidia driver we use (361.28): I tested 5.0.1 on my workstation (running both client and server there) with driver 364.16 and there it works without a problem. A test between my workstation (PV client) and a different machine (PV server) with driver 352.79 also works. I just tried on a node with an updated nvidia driver (367.27, latest for the specific model of GPU used) and get the same error on the server side with 5.0.1. Trying 5.1.0 (binary from paraview.org for both client and server) and I no longer get the error and PV seems work fine in client-server mode. This might or might not be related, but while retesting http://www.paraview.org/Bug/view.php?id=13802 with 5.1.0 I get an error relating to the OpenGL context on the server when switching to slice mode: paulm@s37n2:~/software/ParaView-5.1.0-Qt4-OpenGL2-MPI-Linux-64bit/bin$ ./pvserver --use-offscreen-rendering Waiting for client... Connection URL: cs://s37n2.int.elvis.surfsara.nl:1 Accepting connection(s): s37n2.int.elvis.surfsara.nl:1 Client connected. Warning: In /home/kitware/dashboards/buildbot/paraview-debian6dash-linux-shared-release_opengl2_qt4_superbuild/source-paraview/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 616 vtkXOpenGLRenderWindow (0x30b0eb0): 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 earlier versions of OpenGL but some features may not work. Segmentation fault (core dumped) The supported OpenGL version is 4.2.0, so I don't understand why the context is not 3.2 compatible: $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 ... client glx vendor string: NVIDIA Corporation, NVIDIA Corporation client glx version string: 1.4 ... OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 780 Ti/PCIe/SSE2 OpenGL version string: 4.5.0 NVIDIA 367.27 The nvidia driver used is 367.27, Debian 7.11 (wheezy), 64-bit Paul ___ 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] Client-server mode fails with 5.0.1
On 06/27/2016 05:29 PM, Paul Melis wrote: On 04/19/2016 01:04 PM, Paul Melis wrote: Hi Utkarsh, On 18-04-16 20:04, Utkarsh Ayachit wrote: This has always worked for me with earlier versions of ParaView, but something seems to have changed. It could be the newer NVidia driver we use since a few weeks, but like I said, I don't see issues with any other OpenGL application. Paul, can you try with ParaView 5.0.0 and 4.4 binaries as well? Since those worked before, let's see if it's a NVIdia driver change that's affecting ParaView. 4.4 works without problem in client-server mode (although I can't seem to get subsampled rendering during interaction working, no matter what remote render settings I try). 5.0.0 shows the same GLX-related issue as 5.0.1. It smells like an interaction between the new OpenGL2 backend and the NVidia driver we use (361.28): I tested 5.0.1 on my workstation (running both client and server there) with driver 364.16 and there it works without a problem. A test between my workstation (PV client) and a different machine (PV server) with driver 352.79 also works. I just tried on a node with an updated nvidia driver (367.27, latest for the specific model of GPU used) and get the same error on the server side with 5.0.1. Trying 5.1.0 (binary from paraview.org for both client and server) and I no longer get the error and PV seems work fine in client-server mode. This might or might not be related, but while retesting http://www.paraview.org/Bug/view.php?id=13802 with 5.1.0 I get an error relating to the OpenGL context on the server when switching to slice mode: paulm@s37n2:~/software/ParaView-5.1.0-Qt4-OpenGL2-MPI-Linux-64bit/bin$ ./pvserver --use-offscreen-rendering Waiting for client... Connection URL: cs://s37n2.int.elvis.surfsara.nl:1 Accepting connection(s): s37n2.int.elvis.surfsara.nl:1 Client connected. Warning: In /home/kitware/dashboards/buildbot/paraview-debian6dash-linux-shared-release_opengl2_qt4_superbuild/source-paraview/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 616 vtkXOpenGLRenderWindow (0x30b0eb0): 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 earlier versions of OpenGL but some features may not work. Segmentation fault (core dumped) The supported OpenGL version is 4.2.0, so I don't understand why the context is not 3.2 compatible: $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 ... client glx vendor string: NVIDIA Corporation, NVIDIA Corporation client glx version string: 1.4 ... OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 780 Ti/PCIe/SSE2 OpenGL version string: 4.5.0 NVIDIA 367.27 The nvidia driver used is 367.27, Debian 7.11 (wheezy), 64-bit Paul ___ 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] Client-server mode fails with 5.0.1
On 04/19/2016 01:04 PM, Paul Melis wrote: Hi Utkarsh, On 18-04-16 20:04, Utkarsh Ayachit wrote: This has always worked for me with earlier versions of ParaView, but something seems to have changed. It could be the newer NVidia driver we use since a few weeks, but like I said, I don't see issues with any other OpenGL application. Paul, can you try with ParaView 5.0.0 and 4.4 binaries as well? Since those worked before, let's see if it's a NVIdia driver change that's affecting ParaView. 4.4 works without problem in client-server mode (although I can't seem to get subsampled rendering during interaction working, no matter what remote render settings I try). 5.0.0 shows the same GLX-related issue as 5.0.1. It smells like an interaction between the new OpenGL2 backend and the NVidia driver we use (361.28): I tested 5.0.1 on my workstation (running both client and server there) with driver 364.16 and there it works without a problem. A test between my workstation (PV client) and a different machine (PV server) with driver 352.79 also works. I just tried on a node with an updated nvidia driver (367.27, latest for the specific model of GPU used) and get the same error on the server side with 5.0.1. Trying 5.1.0 (binary from paraview.org for both client and server) and I no longer get the error and PV seems work fine in client-server mode. Paul ___ 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: Comparison of Visit and ParaView development
Hi all, Thanks for all the replies and sudden bug report action ;-) I haven't had the time to check the bugs that got updated, will try to do that soon. Regards, Paul On 16-06-16 19:06, Scott, W Alan wrote: Paul, I looked at a few of the bugs listed below. I replicated 15944, this would impact my users. It's on Sandia's list. 13802 works correctly on 5.0.1. Note that you are creating 2.6 billion cells, and from what I can tell, you are running out of memory on your server side. I was able to get this to work with 8 nodes of a cluster. Try running the View/ Memory Inspector, it will tell you how much pressure you are putting on your memory. Alan -Original Message- From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Paul Melis Sent: Thursday, June 16, 2016 2:52 AM To: Geveci, Berk (External Contact) <berk.gev...@kitware.com>; Sven Kramer <svenkrame...@gmail.com> Cc: ParaView <paraview@paraview.org> Subject: [EXTERNAL] Re: [Paraview] Comparison of Visit and ParaView development Hi, On 15-06-16 16:18, Berk Geveci wrote: I believe that the main differentiator between ParaView and other vis tools out there is the broad functionality _and_ the code quality. Having the two together is really tough but our community managed this with a heavy emphasis on code review and code testing. I strongly recommend that folks look at the software processes used to develop VTK & ParaView as well as the huge amount of testing (both test quantity and platform coverage) that we do before every single commit in addition to nightly. There is a very good overlap between the CMake, CTest & CDash communities and the VTK/ParaView development communities and there is very good reason behind this. Slightly off-topic (not fully about ParaView vs VisIt), but I always wondered about the development process of VTK/ParaView with respect to bug reports. There seem to be a huge number of reported bugs for ParaView (and a few for VTK), ranging from crashes to incorrect functionality to feature requests. Over the years I have entered more than two dozen myself, but was always surprised about the lack of response, especially when reporting things that were easily reproducible and/or crasher bugs (e.g. VTK #10528, ParaView #15291, ParaView #15944, ParaView #13802). Now, I understand that what's not working for me might not be important to others, so, of course, assigning priorty and doing actual fixes for reports is done by the developer community. A second "handicap" in this respect is undoubtedly the fact that KitWare is a business and so has different priorities than a bunch of hackers working mostly in their spare time on their pet project. But basically anything reported these days immediately gets status "backlog" and I would guesstimate getting a response to a report only about 25% of the time. I report bugs quite often for other open-source projects (and try to enter concise reports with a testcase), but with ParaView/VTK I get the feeling it's not worth the trouble, which is a shame. Actually getting back on topic: the one or two times I reported a bug in VisIt I got a reply and fix quickly! Furthermore, ParaView seems quite easy to segfault and it happens even with moderately complex pipelines and modest datasets. Parallel volume rendering has been broken for ages (or is it fixed these days? Can't tell, ParaView #13801 did not get any replies). Some examples shown on the wiki cause Python errors (e.g. #15291, #12796). And so on. So the comment above about code quality making ParaView stand out from other visualization tools is a bit a stretch in my opinion. I would certainly not call ParaView "stable". In fact, in the introductory scivis courses we teach with ParaView we always warn people that crashes are to be expected regularly and even during the course assignments they sometimes happen. The development process as mentioned by Berk is indeed impressive, but seems mostly focused on preventing regressions in existing functionality. This is a worthy goal in itself, but is only one half of the story when it comes to guaranteeing code quality. The things that aren't working (see bug reports) are maybe not getting the attention they deserve, but are apparently things folks run into when using ParaView, so they signal something real. After the stuff above I wanted to finish on a less critical note :) I prefer using ParaView over VisIt mostly because of being able to build a pipeline and prefer ParaView's nice single-window GUI over VisIt's a-window-here-a-window-there-a-window-everywhere approach. They are both good and useful tools and are work-horses for scivis tasks. Whenever I get a request from an HPC user which one to use I recommend ParaView, as it is easier to get into for basic scivis work. Regards, Paul -- Paul Melis | Visualization group leader & developer | SURFsara
Re: [Paraview] Comparison of Visit and ParaView development
Hi, On 15-06-16 16:18, Berk Geveci wrote: I believe that the main differentiator between ParaView and other vis tools out there is the broad functionality _and_ the code quality. Having the two together is really tough but our community managed this with a heavy emphasis on code review and code testing. I strongly recommend that folks look at the software processes used to develop VTK & ParaView as well as the huge amount of testing (both test quantity and platform coverage) that we do before every single commit in addition to nightly. There is a very good overlap between the CMake, CTest & CDash communities and the VTK/ParaView development communities and there is very good reason behind this. Slightly off-topic (not fully about ParaView vs VisIt), but I always wondered about the development process of VTK/ParaView with respect to bug reports. There seem to be a huge number of reported bugs for ParaView (and a few for VTK), ranging from crashes to incorrect functionality to feature requests. Over the years I have entered more than two dozen myself, but was always surprised about the lack of response, especially when reporting things that were easily reproducible and/or crasher bugs (e.g. VTK #10528, ParaView #15291, ParaView #15944, ParaView #13802). Now, I understand that what's not working for me might not be important to others, so, of course, assigning priorty and doing actual fixes for reports is done by the developer community. A second "handicap" in this respect is undoubtedly the fact that KitWare is a business and so has different priorities than a bunch of hackers working mostly in their spare time on their pet project. But basically anything reported these days immediately gets status "backlog" and I would guesstimate getting a response to a report only about 25% of the time. I report bugs quite often for other open-source projects (and try to enter concise reports with a testcase), but with ParaView/VTK I get the feeling it's not worth the trouble, which is a shame. Actually getting back on topic: the one or two times I reported a bug in VisIt I got a reply and fix quickly! Furthermore, ParaView seems quite easy to segfault and it happens even with moderately complex pipelines and modest datasets. Parallel volume rendering has been broken for ages (or is it fixed these days? Can't tell, ParaView #13801 did not get any replies). Some examples shown on the wiki cause Python errors (e.g. #15291, #12796). And so on. So the comment above about code quality making ParaView stand out from other visualization tools is a bit a stretch in my opinion. I would certainly not call ParaView "stable". In fact, in the introductory scivis courses we teach with ParaView we always warn people that crashes are to be expected regularly and even during the course assignments they sometimes happen. The development process as mentioned by Berk is indeed impressive, but seems mostly focused on preventing regressions in existing functionality. This is a worthy goal in itself, but is only one half of the story when it comes to guaranteeing code quality. The things that aren't working (see bug reports) are maybe not getting the attention they deserve, but are apparently things folks run into when using ParaView, so they signal something real. After the stuff above I wanted to finish on a less critical note :) I prefer using ParaView over VisIt mostly because of being able to build a pipeline and prefer ParaView's nice single-window GUI over VisIt's a-window-here-a-window-there-a-window-everywhere approach. They are both good and useful tools and are work-horses for scivis tasks. Whenever I get a request from an HPC user which one to use I recommend ParaView, as it is easier to get into for basic scivis work. Regards, Paul -- Paul Melis | Visualization group leader & developer | SURFsara | | Science Park 140 | 1098 XG Amsterdam | | T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl | ___ 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] Client-server mode fails with 5.0.1
Hi Utkarsh, On 18-04-16 20:04, Utkarsh Ayachit wrote: This has always worked for me with earlier versions of ParaView, but something seems to have changed. It could be the newer NVidia driver we use since a few weeks, but like I said, I don't see issues with any other OpenGL application. Paul, can you try with ParaView 5.0.0 and 4.4 binaries as well? Since those worked before, let's see if it's a NVIdia driver change that's affecting ParaView. 4.4 works without problem in client-server mode (although I can't seem to get subsampled rendering during interaction working, no matter what remote render settings I try). 5.0.0 shows the same GLX-related issue as 5.0.1. It smells like an interaction between the new OpenGL2 backend and the NVidia driver we use (361.28): I tested 5.0.1 on my workstation (running both client and server there) with driver 364.16 and there it works without a problem. A test between my workstation (PV client) and a different machine (PV server) with driver 352.79 also works. Paul -- Paul Melis | Visualization group leader & developer | SURFsara | | Science Park 140 | 1098 XG Amsterdam | | T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl | ___ 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] Client-server mode fails with 5.0.1
Hi Alan, On 04/18/2016 06:48 PM, Scott, W Alan wrote: Paul, Ssh -X is not working with newest ParaView. X forwarding does not support the needed version of OpenGL for ParaView 5.0.1. Could that be your problem? Err, I'm not sure where the X forwarding suddenly comes from, or why you would want to use it in ParaView client-server mode? I'm simply running the client locally on my workstation and one or more server processes on our render cluster. This has always worked for me with earlier versions of ParaView, but something seems to have changed. It could be the newer NVidia driver we use since a few weeks, but like I said, I don't see issues with any other OpenGL application. Paul Alan -Original Message- From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Paul Melis Sent: Monday, April 18, 2016 3:55 AM To: paraview@paraview.org Subject: [EXTERNAL] [Paraview] Client-server mode fails with 5.0.1 Hi, With official binaries of 5.0.1 on Linux 64-bit for both server and client nodes I get the following error directly after connecting the client: paulm@s37n1:~/software/ParaView-5.0.1-Qt4-OpenGL2-MPI-Linux-64bit/bin$ ./pvserver --use-offscreen-rendering Waiting for client... Connection URL: cs://s37n1.int.elvis.surfsara.nl:1 Accepting connection(s): s37n1.int.elvis.surfsara.nl:1 Client connected. X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 135 (GLX) Minor opcode of failed request: 34 () Serial number of failed request: 30 Current serial number in output stream: 31 DISPLAY is set correctly, in glxinfo I see nothing strange, glxgears runs without issues (see below). The message "insufficient resources" is a bit puzzling. I see no problem with other OpenGL applications. I also tried server binaries I compiled myself, but that gives the same error. Other than the EGL stuff in 5.0 is there something different in the way ParaView is trying to initialize OpenGL/GLX that could cause the above error? Regards, Paul paulm@s37n1:~$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 86354 frames in 5.0 seconds = 17270.654 FPS 96998 frames in 5.0 seconds = 19399.479 FPS ^C paulm@s37n1:~$ glxgears name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_buffer_age, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_NV_delay_before_swap, GLX_EXT_stereo_tree, GLX_ARB_context_flush_control, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_buffer_age, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_copy_image, GLX_NV_copy_buffer, GLX_NV_multisample_coverage, GLX_NV_video_capture, GLX_EXT_create_context_es_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_NV_delay_before_swap, GLX_EXT_stereo_tree, GLX_ARB_context_flush_control GLX version: 1.4 GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_buffer_age, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_NV_delay_before_swap, GLX_EXT_stereo_tree, GLX_ARB_context_flush_control, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 780 Ti/PCIe/SSE2 OpenGL version string: 4.5.0 NVIDIA 361
[Paraview] Client-server mode fails with 5.0.1
Hi, With official binaries of 5.0.1 on Linux 64-bit for both server and client nodes I get the following error directly after connecting the client: paulm@s37n1:~/software/ParaView-5.0.1-Qt4-OpenGL2-MPI-Linux-64bit/bin$ ./pvserver --use-offscreen-rendering Waiting for client... Connection URL: cs://s37n1.int.elvis.surfsara.nl:1 Accepting connection(s): s37n1.int.elvis.surfsara.nl:1 Client connected. X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 135 (GLX) Minor opcode of failed request: 34 () Serial number of failed request: 30 Current serial number in output stream: 31 DISPLAY is set correctly, in glxinfo I see nothing strange, glxgears runs without issues (see below). The message "insufficient resources" is a bit puzzling. I see no problem with other OpenGL applications. I also tried server binaries I compiled myself, but that gives the same error. Other than the EGL stuff in 5.0 is there something different in the way ParaView is trying to initialize OpenGL/GLX that could cause the above error? Regards, Paul paulm@s37n1:~$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 86354 frames in 5.0 seconds = 17270.654 FPS 96998 frames in 5.0 seconds = 19399.479 FPS ^C paulm@s37n1:~$ glxgears name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_buffer_age, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_NV_delay_before_swap, GLX_EXT_stereo_tree, GLX_ARB_context_flush_control, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_buffer_age, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_copy_image, GLX_NV_copy_buffer, GLX_NV_multisample_coverage, GLX_NV_video_capture, GLX_EXT_create_context_es_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_NV_delay_before_swap, GLX_EXT_stereo_tree, GLX_ARB_context_flush_control GLX version: 1.4 GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_buffer_age, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_EXT_create_context_es_profile, GLX_EXT_create_context_es2_profile, GLX_ARB_create_context_robustness, GLX_NV_delay_before_swap, GLX_EXT_stereo_tree, GLX_ARB_context_flush_control, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_NV_copy_image, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 780 Ti/PCIe/SSE2 OpenGL version string: 4.5.0 NVIDIA 361.28 OpenGL extensions: GL_AMD_multi_draw_indirect, GL_AMD_seamless_cubemap_per_texture, GL_ARB_arrays_of_arrays, GL_ARB_base_instance, GL_ARB_bindless_texture, GL_ARB_blend_func_extended, GL_ARB_buffer_storage, GL_ARB_clear_buffer_object, GL_ARB_clear_texture, GL_ARB_clip_control, GL_ARB_color_buffer_float, GL_ARB_compatibility, GL_ARB_compressed_texture_pixel_storage, GL_ARB_conservative_depth, GL_ARB_compute_shader, GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted, GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_cull_distance, GL_ARB_debug_output, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_derivative_control, GL_ARB_direct_state_access, GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, GL_ARB_draw_indirect, GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, GL_ARB_enhanced_layouts, GL_ARB_ES2_compatibility, GL_ARB_ES3_compatibility, GL_ARB_ES3_1_compatibility, --
Re: [Paraview] Xdmf weirdness and question
On 01/14/13 17:33, Paul Melis wrote: I use the following Xdmf file to read this set into PV 3.14.1: ?xml version=1.0 ? !DOCTYPE Xdmf SYSTEM Xdmf.dtd [] Xdmf Domain Grid Name=TheGrid GridType=Uniform Topology TopologyType=3DRectMesh Dimensions=4096 4096 160/ Geometry GeometryType=VXVYVZ DataItem Dimensions=4096 NumberType=Float Precision=4 Format=HDFql200.hdf:/x/DataItem DataItem Dimensions=4096 NumberType=Float Precision=4 Format=HDFql200.hdf:/y/DataItem DataItem Dimensions=160 NumberType=Float Precision=4 Format=HDFql200.hdf:/zf/DataItem /Geometry Attribute Name=ql AttributeType=Scalar Center=Node DataItem DataType=Float Precision=4 Dimensions=4096 4096 160 Format=HDFql200.hdf:/ql/DataItem /Attribute /Grid /Domain /Xdmf This doesn't work unfortunately, as PV turns it into a grid of 160x4096x4096 (and no data is visible at all, even though the number of cells and points seems to be correct). I don't see where the reordering of axes comes from. Looking at Utilities/Xdmf2/libsrc/XdmfGeometry.cxx I think I got the Geometry stuff correct. Does anybody see what is wrong? Ouch, seems I missed the line Dimensions are specified with the slowest varying dimension first (i.e. KJI order). in the Xdmf spec... Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Xdmf weirdness and question
Hi all,
I have a rectilinear dataset of 4096x4096x160 floats with constant
spacing in X and Y, but varying spacing in Z. I've put the data in a
single HDF5 file (for now) with the following layout:
HDF5 ql200.hdf {
GROUP / {
DATASET ql {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 4096, 4096, 160 ) / ( 4096, 4096, 160 ) }
}
DATASET x {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 4096 ) / ( 4096 ) }
}
DATASET y {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 4096 ) / ( 4096 ) }
}
DATASET zf {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 160 ) / ( 160 ) }
}
}
}
The point coordinates per axis are in the X, Y and Z(f) datasets.
I use the following Xdmf file to read this set into PV 3.14.1:
?xml version=1.0 ?
!DOCTYPE Xdmf SYSTEM Xdmf.dtd []
Xdmf
Domain
Grid Name=TheGrid GridType=Uniform
Topology TopologyType=3DRectMesh Dimensions=4096 4096 160/
Geometry GeometryType=VXVYVZ
DataItem Dimensions=4096 NumberType=Float Precision=4
Format=HDFql200.hdf:/x/DataItem
DataItem Dimensions=4096 NumberType=Float Precision=4
Format=HDFql200.hdf:/y/DataItem
DataItem Dimensions=160 NumberType=Float Precision=4
Format=HDFql200.hdf:/zf/DataItem
/Geometry
Attribute Name=ql AttributeType=Scalar Center=Node
DataItem DataType=Float Precision=4 Dimensions=4096 4096
160 Format=HDFql200.hdf:/ql/DataItem
/Attribute
/Grid
/Domain
/Xdmf
This doesn't work unfortunately, as PV turns it into a grid of
160x4096x4096 (and no data is visible at all, even though the number of
cells and points seems to be correct). I don't see where the reordering
of axes comes from. Looking at Utilities/Xdmf2/libsrc/XdmfGeometry.cxx I
think I got the Geometry stuff correct. Does anybody see what is wrong?
Secondly, for rendering this set in parallel I was wondering if PV can
automatically read in subsets of the data from the single HDF5 file per
node (i.e. hyperslab reading), or that a manual split of the data is
needed anyway?
Thanks in advance for any help,
Paul
___
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
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division, division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote:
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your
sphere are the same it seems.
On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote:
Something's amiss. Attached are images of what I see when I interact
with a default sphere.
Utkarsh
On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl wrote:
Does the LOD render use quadric clustering by the way?
And if so, should the LOD resolution setting produce the same mesh
during interactive rendering as when applying a Quadric Clustering
filter to the same input with the same resolution settings?
On 06/20/2012 03:40 PM, Paul Melis wrote:
Hmm, maybe not a good test, as depending on the sphere resolution a the
quadric clustering will produce the same results for a range of
dimension settings (i.e. 10^3 and up)
On 06/20/2012 03:36 PM, Paul Melis wrote:
I actually get the same result when using the builtin server.
On 06/20/2012 03:34 PM, Paul Melis wrote:
Same result, I see no difference in meshes used during interaction
between 10x10x10 and 160x160x160 for LOD Resolution. Just to make
sure:
- LOD Threshold is checked, set to 0.00 MBytes
- Remote Render Threshold is checked, set to 0 MBytes
Paul
On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote:
Try reproducing with sphere source. Any luck?
On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl
wrote:
It's already at 0 (see below).
Paul
On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote:
WHat is the LOD Threshold set to? Try setting it to 0.
Utkarsh
On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl
wrote:
Hi,
I'm doing remote rendering with PV 3.14.0, with quite a large set
(isosurface of 98M tris) on 16 render nodes, each with a GTX460
and 12 GB RAM (Linux 64-bit cluster btw).
This model renders like a dog when interacting. I've checked the
subsampling settings, compression settings and LOD settings to
see make sure I'm actually using lower resolution rendering and
model decimation during interaction
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division, division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote:
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your
sphere are the same it seems.
On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote:
Something's amiss. Attached are images of what I see when I interact
with a default sphere.
Utkarsh
On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl wrote:
Does the LOD render use quadric clustering by the way?
And if so, should the LOD resolution setting produce the same mesh
during interactive rendering as when applying a Quadric Clustering
filter to the same input with the same resolution settings?
On 06/20/2012 03:40 PM, Paul Melis wrote:
Hmm, maybe not a good test, as depending on the sphere resolution a
the
quadric clustering will produce the same results for a range of
dimension settings (i.e. 10^3 and up)
On 06/20/2012 03:36 PM, Paul Melis wrote:
I actually get the same result when using the builtin server.
On 06/20/2012 03:34 PM, Paul Melis wrote:
Same result, I see no difference in meshes used during interaction
between 10x10x10 and 160x160x160 for LOD Resolution. Just to make
sure:
- LOD Threshold is checked, set to 0.00 MBytes
- Remote Render Threshold is checked, set to 0 MBytes
Paul
On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote:
Try reproducing with sphere source. Any luck?
On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl
wrote:
It's already at 0 (see below).
Paul
On 06/20/2012 03:16 PM
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() + 10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division, division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote:
Look closely. They are not the same. Look the wireframing around the
centre of the sphere closely.
On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote:
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your
sphere are the same it seems.
On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote:
Something's amiss. Attached are images of what I see when I interact
with a default sphere.
Utkarsh
On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl
wrote:
Does the LOD render use quadric clustering by the way?
And if so, should the LOD resolution setting produce the same mesh
during interactive rendering as when applying a Quadric Clustering
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
I applied it to the 3.14.1 sources. Perhaps I should indeed switch to
the git version.
Is the 3.14 client compatible with the server code in git?
On 06/21/2012 02:22 PM, Utkarsh Ayachit wrote:
With git-master, I verified that changing the slider indeed changes
the LOD refinement for a Sphere (phi/theta resolutions = 800). Also
try running ParaView with -dr option just to avoid any anomolies due
to the settings (for me, however, it works fine even when -dr isn't
specified.)
Utkarsh
On Thu, Jun 21, 2012 at 8:18 AM, Utkarsh Ayachit
utkarsh.ayac...@kitware.com wrote:
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() +
10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl
wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is
the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my case.
Especially for a very large mesh I would expect 10^3 versus 160^3 to
make a whopping difference.
On 06/20
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Argh, I see that git needs Qt 4.7.x :-/
On 06/21/2012 02:26 PM, Paul Melis wrote:
I applied it to the 3.14.1 sources. Perhaps I should indeed switch to
the git version.
Is the 3.14 client compatible with the server code in git?
On 06/21/2012 02:22 PM, Utkarsh Ayachit wrote:
With git-master, I verified that changing the slider indeed changes
the LOD refinement for a Sphere (phi/theta resolutions = 800). Also
try running ParaView with -dr option just to avoid any anomolies due
to the settings (for me, however, it works fine even when -dr isn't
specified.)
Utkarsh
On Thu, Jun 21, 2012 at 8:18 AM, Utkarsh Ayachit
utkarsh.ayac...@kitware.com wrote:
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() +
10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a
printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(),
this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM, Utkarsh Ayachit wrote:
Ok, I do some funkiness in that regard. Let me try to track that down.
Utkarsh
On Wed, Jun 20, 2012 at 10:06 AM, Paul Melis paul.me...@sara.nl
wrote:
Ah, missed that. But my issue is not that the LOD-rendering mesh is
the
same as the fullres one (it's not, as expected), but that the LOD
resolution setting does not seem to influence the LOD mesh in my
case.
Especially
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Forcing delivery (whatever that means ;-)) in
vtkGeometryRepresentation::ProcessViewRequest() seems to solve it with
3.14.1:
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
this-Decimator-SetNumberOfDivisions(division, division, division);
// ADDED PM
outInfo-Set(vtkPVRenderView::NEEDS_DELIVERY(), 1);
}
this-LODDeliveryFilter-ProcessViewRequest(inInfo);
Paul
On 06/21/2012 02:22 PM, Utkarsh Ayachit wrote:
With git-master, I verified that changing the slider indeed changes
the LOD refinement for a Sphere (phi/theta resolutions = 800). Also
try running ParaView with -dr option just to avoid any anomolies due
to the settings (for me, however, it works fine even when -dr isn't
specified.)
Utkarsh
On Thu, Jun 21, 2012 at 8:18 AM, Utkarsh Ayachit
utkarsh.ayac...@kitware.com wrote:
Paul,
What version did you apply the patch to?
Utkarsh
On Thu, Jun 21, 2012 at 8:14 AM, Paul Melis paul.me...@sara.nl wrote:
Thanks for the patch. I applied it but get really strange results I
can't quite explain. I can see the correct values now appearing in
vtkGeometryRepresentation::ProcessViewRequest() and the correct division
value is set on the decimator (e.g. getting the X division value after
being set returns the correct number).
But I still don't see any change in the mesh used during interaction for
different resolution values. It's as though only the first value set is
used. Is there some kind of caching of the mesh going on?
Regards,
Paul
On 06/21/2012 01:46 PM, Utkarsh Ayachit wrote:
Paul,
Attached is the patch. It is possible to have been introduced around
3.10. I cannot remember when the views were refactored 3.10 or 3.12,
but that would be the time when it would have stopped working.
http://paraview.org/Bug/view.php?id=13255
Utkarsh
On Thu, Jun 21, 2012 at 6:35 AM, Paul Melis paul.me...@sara.nl wrote:
Ok, great. Actually just tried a few older PV versions, still seemed to
work in 3.8.1, but 3.10.1 is where the bug shows up. Does that sound
like the right timeline?
Paul
On 06/21/2012 12:15 PM, Utkarsh Ayachit wrote:
Paul,
Thanks for tracking this down. I think I know the problem. I remember
changing vtkPVRenderView to accept LOD resolution as a normalized
value between [0,1], clearly I forgot to update the GUI. I'll push a
fix a post a patch.
Utkarsh
On Thu, Jun 21, 2012 at 5:35 AM, Paul Melis paul.me...@sara.nl wrote:
Hi Utkarsh,
I looked a bit into the code and the values used in
pqGlobalRenderViewOptions::applyChanges() seem to be okay, e.g.
void pqGlobalRenderViewOptions::applyChanges()
{
...
if (this-Internal-enableLOD-isChecked())
{
printf(pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = %d\n,
this-Internal-lodResolution-value());
settings-setValue(LODThreshold,
this-Internal-lodThreshold-value() / 10.0);
printf(pqGlobalRenderViewOptions::applyChanges(): setting
LODResolution to %d\n, 160-this-Internal-lodResolution-value() +
10);
settings-setValue(LODResolution,
160-this-Internal-lodResolution-value() + 10);
gives me output like
pqGlobalRenderViewOptions::applyChanges():
this-Internal-lodResolution-value() = 106
pqGlobalRenderViewOptions::applyChanges(): setting LODResolution to 64
But when I look at the applied settings in
vtkGeometryRepresentation::ProcessViewRequest(), after adding a printf()
like this:
void vtkPVRenderView::SetRequestLODRendering(bool enable)
{
if (enable)
{
this-RequestInformation-Set(USE_LOD(), 1);
printf(vtkPVRenderView::SetRequestLODRendering():
this-LODResolution = %g\n, this-LODResolution);
this-RequestInformation-Set(LOD_RESOLUTION(), this-LODResolution);
}
else
this always outputs
vtkPVRenderView::SetRequestLODRendering(): this-LODResolution = 1
no matter what the slider is set to, leading to
vtkGeometryRepresentation::ProcessViewRequest() always setting the
decimator to 160^3:
...
// this is where we will look to see on what nodes are we going to
render and
// render set that up.
bool lod = this-SuppressLOD? false :
(inInfo-Has(vtkPVRenderView::USE_LOD()) == 1);
if (lod)
{
if (inInfo-Has(vtkPVRenderView::LOD_RESOLUTION()))
{
int division = static_castint(150 *
inInfo-Get(vtkPVRenderView::LOD_RESOLUTION())) + 10;
printf(SETTING DECIMATOR TO %d^3 DIVISIONS\n, division);
this-Decimator-SetNumberOfDivisions(division, division,
division);
}
...
Does this make any sense to you?
Regards,
Paul
PS: The other project we had contact on is on my todo-stack, hope to
pick it up again in the near future :-/
On 06/20/2012 04:14 PM
[Paraview] Desktop-delivery and LOD settings: no influence?
Hi, I'm doing remote rendering with PV 3.14.0, with quite a large set (isosurface of 98M tris) on 16 render nodes, each with a GTX460 and 12 GB RAM (Linux 64-bit cluster btw). This model renders like a dog when interacting. I've checked the subsampling settings, compression settings and LOD settings to see make sure I'm actually using lower resolution rendering and model decimation during interaction. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip). But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than 10 per direction (or per data piece assigned per process, when showing Process Id Scalars). I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Same result, I see no difference in meshes used during interaction between 10x10x10 and 160x160x160 for LOD Resolution. Just to make sure: - LOD Threshold is checked, set to 0.00 MBytes - Remote Render Threshold is checked, set to 0 MBytes Paul On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote: Try reproducing with sphere source. Any luck? On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl wrote: It's already at 0 (see below). Paul On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote: WHat is the LOD Threshold set to? Try setting it to 0. Utkarsh On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm doing remote rendering with PV 3.14.0, with quite a large set (isosurface of 98M tris) on 16 render nodes, each with a GTX460 and 12 GB RAM (Linux 64-bit cluster btw). This model renders like a dog when interacting. I've checked the subsampling settings, compression settings and LOD settings to see make sure I'm actually using lower resolution rendering and model decimation during interaction. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip). But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than 10 per direction (or per data piece assigned per process, when showing Process Id Scalars). I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
I actually get the same result when using the builtin server. On 06/20/2012 03:34 PM, Paul Melis wrote: Same result, I see no difference in meshes used during interaction between 10x10x10 and 160x160x160 for LOD Resolution. Just to make sure: - LOD Threshold is checked, set to 0.00 MBytes - Remote Render Threshold is checked, set to 0 MBytes Paul On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote: Try reproducing with sphere source. Any luck? On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl wrote: It's already at 0 (see below). Paul On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote: WHat is the LOD Threshold set to? Try setting it to 0. Utkarsh On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm doing remote rendering with PV 3.14.0, with quite a large set (isosurface of 98M tris) on 16 render nodes, each with a GTX460 and 12 GB RAM (Linux 64-bit cluster btw). This model renders like a dog when interacting. I've checked the subsampling settings, compression settings and LOD settings to see make sure I'm actually using lower resolution rendering and model decimation during interaction. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip). But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than 10 per direction (or per data piece assigned per process, when showing Process Id Scalars). I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
It's already at 0 (see below). Paul On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote: WHat is the LOD Threshold set to? Try setting it to 0. Utkarsh On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm doing remote rendering with PV 3.14.0, with quite a large set (isosurface of 98M tris) on 16 render nodes, each with a GTX460 and 12 GB RAM (Linux 64-bit cluster btw). This model renders like a dog when interacting. I've checked the subsampling settings, compression settings and LOD settings to see make sure I'm actually using lower resolution rendering and model decimation during interaction. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip). But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than 10 per direction (or per data piece assigned per process, when showing Process Id Scalars). I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Hmm, maybe not a good test, as depending on the sphere resolution a the quadric clustering will produce the same results for a range of dimension settings (i.e. 10^3 and up) On 06/20/2012 03:36 PM, Paul Melis wrote: I actually get the same result when using the builtin server. On 06/20/2012 03:34 PM, Paul Melis wrote: Same result, I see no difference in meshes used during interaction between 10x10x10 and 160x160x160 for LOD Resolution. Just to make sure: - LOD Threshold is checked, set to 0.00 MBytes - Remote Render Threshold is checked, set to 0 MBytes Paul On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote: Try reproducing with sphere source. Any luck? On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl wrote: It's already at 0 (see below). Paul On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote: WHat is the LOD Threshold set to? Try setting it to 0. Utkarsh On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm doing remote rendering with PV 3.14.0, with quite a large set (isosurface of 98M tris) on 16 render nodes, each with a GTX460 and 12 GB RAM (Linux 64-bit cluster btw). This model renders like a dog when interacting. I've checked the subsampling settings, compression settings and LOD settings to see make sure I'm actually using lower resolution rendering and model decimation during interaction. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip). But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than 10 per direction (or per data piece assigned per process, when showing Process Id Scalars). I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your sphere are the same it seems. On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote: Something's amiss. Attached are images of what I see when I interact with a default sphere. Utkarsh On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl wrote: Does the LOD render use quadric clustering by the way? And if so, should the LOD resolution setting produce the same mesh during interactive rendering as when applying a Quadric Clustering filter to the same input with the same resolution settings? On 06/20/2012 03:40 PM, Paul Melis wrote: Hmm, maybe not a good test, as depending on the sphere resolution a the quadric clustering will produce the same results for a range of dimension settings (i.e. 10^3 and up) On 06/20/2012 03:36 PM, Paul Melis wrote: I actually get the same result when using the builtin server. On 06/20/2012 03:34 PM, Paul Melis wrote: Same result, I see no difference in meshes used during interaction between 10x10x10 and 160x160x160 for LOD Resolution. Just to make sure: - LOD Threshold is checked, set to 0.00 MBytes - Remote Render Threshold is checked, set to 0 MBytes Paul On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote: Try reproducing with sphere source. Any luck? On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl wrote: It's already at 0 (see below). Paul On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote: WHat is the LOD Threshold set to? Try setting it to 0. Utkarsh On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm doing remote rendering with PV 3.14.0, with quite a large set (isosurface of 98M tris) on 16 render nodes, each with a GTX460 and 12 GB RAM (Linux 64-bit cluster btw). This model renders like a dog when interacting. I've checked the subsampling settings, compression settings and LOD settings to see make sure I'm actually using lower resolution rendering and model decimation during interaction. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip). But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than 10 per direction (or per data piece assigned per process, when showing Process Id Scalars). I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Does the LOD render use quadric clustering by the way? And if so, should the LOD resolution setting produce the same mesh during interactive rendering as when applying a Quadric Clustering filter to the same input with the same resolution settings? On 06/20/2012 03:40 PM, Paul Melis wrote: Hmm, maybe not a good test, as depending on the sphere resolution a the quadric clustering will produce the same results for a range of dimension settings (i.e. 10^3 and up) On 06/20/2012 03:36 PM, Paul Melis wrote: I actually get the same result when using the builtin server. On 06/20/2012 03:34 PM, Paul Melis wrote: Same result, I see no difference in meshes used during interaction between 10x10x10 and 160x160x160 for LOD Resolution. Just to make sure: - LOD Threshold is checked, set to 0.00 MBytes - Remote Render Threshold is checked, set to 0 MBytes Paul On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote: Try reproducing with sphere source. Any luck? On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl wrote: It's already at 0 (see below). Paul On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote: WHat is the LOD Threshold set to? Try setting it to 0. Utkarsh On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm doing remote rendering with PV 3.14.0, with quite a large set (isosurface of 98M tris) on 16 render nodes, each with a GTX460 and 12 GB RAM (Linux 64-bit cluster btw). This model renders like a dog when interacting. I've checked the subsampling settings, compression settings and LOD settings to see make sure I'm actually using lower resolution rendering and model decimation during interaction. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip). But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than 10 per direction (or per data piece assigned per process, when showing Process Id Scalars). I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Desktop-delivery and LOD settings: no influence?
Ah, missed that. But my issue is not that the LOD-rendering mesh is the same as the fullres one (it's not, as expected), but that the LOD resolution setting does not seem to influence the LOD mesh in my case. Especially for a very large mesh I would expect 10^3 versus 160^3 to make a whopping difference. On 06/20/2012 04:03 PM, Utkarsh Ayachit wrote: Look closely. They are not the same. Look the wireframing around the centre of the sphere closely. On Wed, Jun 20, 2012 at 9:53 AM, Paul Melis paul.me...@sara.nl wrote: Hmmm, amiss at my end or in ParaView? The LOD and non-LOD views of your sphere are the same it seems. On 06/20/2012 03:50 PM, Utkarsh Ayachit wrote: Something's amiss. Attached are images of what I see when I interact with a default sphere. Utkarsh On Wed, Jun 20, 2012 at 9:44 AM, Paul Melis paul.me...@sara.nl wrote: Does the LOD render use quadric clustering by the way? And if so, should the LOD resolution setting produce the same mesh during interactive rendering as when applying a Quadric Clustering filter to the same input with the same resolution settings? On 06/20/2012 03:40 PM, Paul Melis wrote: Hmm, maybe not a good test, as depending on the sphere resolution a the quadric clustering will produce the same results for a range of dimension settings (i.e. 10^3 and up) On 06/20/2012 03:36 PM, Paul Melis wrote: I actually get the same result when using the builtin server. On 06/20/2012 03:34 PM, Paul Melis wrote: Same result, I see no difference in meshes used during interaction between 10x10x10 and 160x160x160 for LOD Resolution. Just to make sure: - LOD Threshold is checked, set to 0.00 MBytes - Remote Render Threshold is checked, set to 0 MBytes Paul On 06/20/2012 03:28 PM, Utkarsh Ayachit wrote: Try reproducing with sphere source. Any luck? On Wed, Jun 20, 2012 at 9:26 AM, Paul Melis paul.me...@sara.nl wrote: It's already at 0 (see below). Paul On 06/20/2012 03:16 PM, Utkarsh Ayachit wrote: WHat is the LOD Threshold set to? Try setting it to 0. Utkarsh On Wed, Jun 20, 2012 at 6:07 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm doing remote rendering with PV 3.14.0, with quite a large set (isosurface of 98M tris) on 16 render nodes, each with a GTX460 and 12 GB RAM (Linux 64-bit cluster btw). This model renders like a dog when interacting. I've checked the subsampling settings, compression settings and LOD settings to see make sure I'm actually using lower resolution rendering and model decimation during interaction. I have enabled LOD Threshold and set the value to 0 (to force LOD usage during interaction, per tooltip). But I don't see any difference in the actual decimated model used during interactive rendering for different LOD Resolution values (checked using surface-with-edges repr and rendering without subsampling). I also don't see how the value for LOD resolution relates to the actual model used. I would expect something like quadric clustering to be used, but when e.g. setting LOD resolution to 10x10x10 the model during interaction uses many more triangles than 10 per direction (or per data piece assigned per process, when showing Process Id Scalars). I just don't see any difference between different LOD resolution settings. Am I missing a setting somewhere? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Extract VOI problems
Hi Dominik, Just curious, but does your output resemble the pics in this bug report? http://paraview.org/Bug/view.php?id=12509 Paul On 03/16/12 19:50, Utkarsh Ayachit wrote: Any more details to reproduce the issue? Can you reproduce it with Wavelet source? I tried with Wavelet and seems to work fine. Utkarsh On Tue, Mar 6, 2012 at 8:32 AM, Dominik Szczerbadomi...@itis.ethz.ch wrote: Hi, As soon as I specify resample rate 1, the output image is damaged (sort of chopped), latest release version on linux 64 bit. I do not remember having it seen before. Anyone with similar findings? Dominik ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Errors with GPU-based volume rendering
Hi Paul, That workaround indeed does the trick for me as well... Thanks! Paul On 12/01/11 00:15, Paul McIntosh wrote: Paul, I see this issue and have yet to try and debug what is going on. However I have a workaround - try saving state even though you see a pink blob then reload the state. I find it works every time - obviously I wish this not to happen at all so I'll provide a test case as soon as I can. Below is some of the error messages I see just FYI Cheers, Paul after uniforms for textures ERROR (x501) Invalid value framebuffer has an attachment error framebuffer has an attachment error SetupRender ERROR (x506) invalid framebuffer operation ext framebuffer has an attachment error framebuffer has an attachment error after uniforms for textures ERROR (x501) Invalid value framebuffer has an attachment error framebuffer has an attachment error SetupRender ERROR (x506) invalid framebuffer operation ext framebuffer has an attachment error framebuffer has an attachment error after uniforms for textures ERROR (x501) Invalid value framebuffer has an attachment error framebuffer has an attachment error SetupRender ERROR (x506) invalid framebuffer operation ext framebuffer has an attachment error framebuffer has an attachment error after uniforms for textures ERROR (x501) Invalid value framebuffer has an attachment error framebuffer has an attachment error SetupRender ERROR (x506) invalid framebuffer operation ext framebuffer has an attachment error framebuffer has an attachment error after uniforms for textures ERROR (x501) Invalid value framebuffer has an attachment error framebuffer has an attachment error -Original Message- From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of David E DeMarle Sent: Thursday, 1 December 2011 1:47 AM To: paul.me...@sara.nl Cc: paraview@paraview.org Subject: Re: [Paraview] Errors with GPU-based volume rendering Sounds like a bug then if 3.8 works and3.8 doesn't on the same setup. It suspect it is in the new rendering architecture that was introduced with 3.10. Please file a bug report with enough information to reproduce the problem so that we can keep an eye on it. David E DeMarle Kitware, Inc. RD Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Nov 24, 2011 at 3:19 AM, Paul Melispaul.me...@sara.nl wrote: On 11/22/2011 10:08 AM, Paul Melis wrote: Is this a problem with my local setup? If so, are there tests I can do to figure out what's wrong? I did some more testing and it is not a problem with my local setup, as I can get correct GPU-based volume rendering with PV 3.12.0 in the following two situations: * Running PV standalone on a render node under VirtualGL, accessed through VNC * Running 1 pvserver on a render node with forced remote rendering (remote rendering threshold enabled and set to 0) However, when I try to use 2 or 4 pvservers (one per render node) I get the purple-square-screwed-up rendering, both with 3.10.1 and 3.12.0. Surprisingly, with 3.8.1 when using 2 or 4 pvservers the GPU-based rendering works... Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Errors with GPU-based volume rendering
On 11/22/2011 10:08 AM, Paul Melis wrote: Is this a problem with my local setup? If so, are there tests I can do to figure out what's wrong? I did some more testing and it is not a problem with my local setup, as I can get correct GPU-based volume rendering with PV 3.12.0 in the following two situations: * Running PV standalone on a render node under VirtualGL, accessed through VNC * Running 1 pvserver on a render node with forced remote rendering (remote rendering threshold enabled and set to 0) However, when I try to use 2 or 4 pvservers (one per render node) I get the purple-square-screwed-up rendering, both with 3.10.1 and 3.12.0. Surprisingly, with 3.8.1 when using 2 or 4 pvservers the GPU-based rendering works... Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Errors with GPU-based volume rendering
Hi, I'm running PV on an 8-node cluster in desktop-delivery mode. Each node has an NVidia Geforce GTX460, NVidia driver 260.19.26, supporting OpenGL 4.1.0. OS is Debian 6.0 x86_64. In case it matters I pass --use-offscreen-rendering to pvserver. With both 3.10.1 and 3.12.0 GPU-based volume rendering is failing. I get purple rectangular regions in the client, presumably the pieces of viewport each node was supposed to render. I get lots of errors from the pvserver processes: after uniforms for textures ERROR (x501) Invalid value framebuffer has an attachment error framebuffer has an attachment error SetupRender ERROR (x506) invalid framebuffer operation ext framebuffer has an attachment error framebuffer has an attachment error [...] render clipped 1 ERROR (x506) invalid framebuffer operation ext render clipped 1 ERROR (x506) invalid framebuffer operation ext render clipped 1 ERROR (x506) invalid framebuffer operation ext render clipped 1 ERROR (x506) invalid framebuffer operation ext render clipped 1 ERROR (x506) invalid framebuffer operation ext render clipped 1 ERROR (x506) invalid framebuffer operation ext render clipped 1 ERROR (x506) invalid framebuffer operation ext render clipped 1 ERROR (x506) invalid framebuffer operation ext [...] Is this a problem with my local setup? If so, are there tests I can do to figure out what's wrong? More info: clients are binaries from paraview.org. The servers are compiled by myself, mostly to enable MPI. E.g. for the 3.12.0 binaries I use: cmake \ -DCMAKE_C_COMPILER=/software/openmpi/gnu/1.4.3/bin/mpicc \ -DCMAKE_CXX_COMPILER=/software/openmpi/gnu/1.4.3/bin/mpicxx \ -DCMAKE_INSTALL_PREFIX=/software/paraview/3.12.0 \ -DCMAKE_BUILD_TYPE=Release \ -DPARAVIEW_BUILD_QT_GUI=ON \ -DPARAVIEW_USE_MPI=ON \ -DPARAVIEW_ENABLE_PYTHON=ON \ -DVTK_USE_MPI:BOOL=ON \ -DVTK_MPIRUN_EXE:FILEPATH=/software/openmpi/gnu/1.4.3/bin/mpirun \ -DPARAVIEW_INSTALL_DEVELOPMENT=ON \ ../ParaView-3.12.0 Best regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Xdmf data duplication
Hi, On 08/16/2011 06:22 PM, Utkarsh Ayachit wrote: If you're writing out data that is already partitioned, you should write it out as a collection of grids. Then each grid in that collection is read on a separate partition. Manual partitioning was something I was hoping to avoid. I figured with HDF5 Paraview might be able to pick out a chunk of unstructured data per node, using HDF5's ability to load a subset of a dataset. But I guess manual splitting it is... Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Xdmf data duplication
Hi Utkarsh, On 08/16/2011 06:22 PM, Utkarsh Ayachit wrote: If you're writing out data that is already partitioned, you should write it out as a collection of grids. Then each grid in that collection is read on a separate partition. I followed your advice, but seem to have hit on another bug, this time with nodes not reading/showing their collection. See the attached Xdmf file, it contains a temporal collection of spatial collections, where there is actually only 1 timestep as it shows the incorrect behaviour. Each spatial grid consists of 16 unstructured grids, read from 16 HDF5 files. The behaviour I'm seeing when loading this dataset on an 8-process PV session is that only 1/8th of the data actually shows up. Looking at the process Id scalars it only has a range of [0,0] and only 1 out of 8 of the hypercolumn-? sets in the multi-block set show any cells and points. This is with PV patched with the code you sent earlier, btw. Loading the same set on a local PV session works fine. I can upload the corresponding HDF5 files, if needed, but these are not public I'm afraid. Regards, Paul ?xml version=1.0 ? !DOCTYPE Xdmf SYSTEM Xdmf.dtd [] Xdmf Domain Grid GridType=Collection CollectionType=Temporal Name=TimeSeries Grid GridType=Collection CollectionType=Spatial Name=SpatialDecomposition Time Value=0 / Grid Name=hypercolumn-0 GridType=Uniform Topology TopologyType=Polyvertex NumberOfElements=3456 / Geometry GeometryType=XYZ DataItem Name=Coordinates NumberType=Float Precision=4 Dimensions=3456 3 Format=HDFout_.hdf5:/positions/DataItem /Geometry Attribute Name=voltage Type=Scalar Center=Node DataItem NumberType=Float Precision=4 Dimensions=3456 1 Format=HDFout_.hdf5:/voltages/DataItem /Attribute Attribute Name=type Type=Scalar Center=Node DataItem NumberType=Int Dimensions=3456 1 Format=HDFout_.hdf5:/types/DataItem /Attribute Attribute Name=rotation Type=Vector Center=Node DataItem NumberType=Float Precision=4 Dimensions=3456 3 Format=HDFout_.hdf5:/rotations/DataItem /Attribute /Grid Grid Name=hypercolumn-1 GridType=Uniform Topology TopologyType=Polyvertex NumberOfElements=3456 / Geometry GeometryType=XYZ DataItem Name=Coordinates NumberType=Float Precision=4 Dimensions=3456 3 Format=HDFout_0001.hdf5:/positions/DataItem /Geometry Attribute Name=voltage Type=Scalar Center=Node DataItem NumberType=Float Precision=4 Dimensions=3456 1 Format=HDFout_0001.hdf5:/voltages/DataItem /Attribute Attribute Name=type Type=Scalar Center=Node DataItem NumberType=Int Dimensions=3456 1 Format=HDFout_0001.hdf5:/types/DataItem /Attribute Attribute Name=rotation Type=Vector Center=Node DataItem NumberType=Float Precision=4 Dimensions=3456 3 Format=HDFout_0001.hdf5:/rotations/DataItem /Attribute /Grid Grid Name=hypercolumn-2 GridType=Uniform Topology TopologyType=Polyvertex NumberOfElements=3456 / Geometry GeometryType=XYZ DataItem Name=Coordinates NumberType=Float Precision=4 Dimensions=3456 3 Format=HDFout_0002.hdf5:/positions/DataItem /Geometry Attribute Name=voltage Type=Scalar Center=Node DataItem NumberType=Float Precision=4 Dimensions=3456 1 Format=HDFout_0002.hdf5:/voltages/DataItem /Attribute Attribute Name=type Type=Scalar Center=Node DataItem NumberType=Int Dimensions=3456 1 Format=HDFout_0002.hdf5:/types/DataItem /Attribute Attribute Name=rotation Type=Vector Center=Node DataItem NumberType=Float Precision=4 Dimensions=3456 3 Format=HDFout_0002.hdf5:/rotations/DataItem /Attribute /Grid Grid Name=hypercolumn-3 GridType=Uniform Topology TopologyType=Polyvertex NumberOfElements=3456 / Geometry GeometryType=XYZ DataItem Name=Coordinates NumberType=Float Precision=4 Dimensions=3456 3 Format=HDFout_0003.hdf5:/positions/DataItem /Geometry Attribute Name=voltage Type=Scalar Center=Node DataItem NumberType=Float Precision=4 Dimensions=3456 1 Format=HDFout_0003.hdf5:/voltages/DataItem /Attribute Attribute Name=type Type=Scalar Center=Node DataItem NumberType=Int Dimensions=3456 1 Format=HDFout_0003.hdf5:/types/DataItem /Attribute Attribute Name=rotation Type=Vector Center=Node DataItem NumberType=Float Precision=4 Dimensions=3456 3 Format=HDFout_0003.hdf5:/rotations/DataItem /Attribute /Grid Grid Name=hypercolumn-4 GridType=Uniform Topology TopologyType=Polyvertex NumberOfElements=3456 / Geometry GeometryType=XYZ DataItem Name=Coordinates NumberType=Float Precision=4 Dimensions=3456 3
Re: [Paraview] Xdmf data duplication
Sure, I have a simplified dataset for you showing the problem. It also shows a crasher bug (load dataset, add process id scalars filter, add histogram - crash) Paul On 08/15/2011 10:27 PM, Utkarsh Ayachit wrote: That sounds like a bug. Can you share the dataset? I can send you an url you can use to upload the dataset directly to us. Utkarsh On Mon, Aug 15, 2011 at 10:54 AM, Paul Melis paul.me...@sara.nl wrote: On 08/15/2011 04:17 PM, Paul Melis wrote: With a dataset stored in Xdmf I get an interesing data duplication result. The set consists of 55296 points, each with associated scalar and vector values. See below for the XML file and HDF5 layout. [...] ?xml version=1.0? Xdmf Domain Grid GridType=Uniform Name=Neurons-0 Topology NodesPerElement=55296 TopologyType=Polyvertex/ Hmmm, I seem to have the Topology tag not completely correct, NodesPerElement should be NumberOfElements. With that correction I get at least the same number of cells as number of points. This makes me wonder about the other attributes I used in the .xmf file. The data duplication issue remains, though. Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Xdmf data duplication
On 08/16/2011 04:23 PM, Utkarsh Ayachit wrote: Thanks for reporting Paul. The issue is now fixed (http://paraview.org/Bug/view.php?id=12527). The fix will make it into git-master at the next gatekeeper review and will be included in 3.12. No problem, thanks for the quick fix! Attached is the patch for same. 2. If the data is unstructrued, we read only on the root node. The user +//can apply D3 or something to repartition the data. Ouch, so for unstructured grids Xdmf isn't such an attractive option. If I were to store the same dataset in .pvtu + .vtu's would I get better automatic data distribution? I must say, I haven't worked with unstructured grids that much yet. Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Xdmf data duplication
Hi,
With a dataset stored in Xdmf I get an interesing data duplication
result. The set consists of 55296 points, each with associated scalar
and vector values. See below for the XML file and HDF5 layout.
It loads fine when running PV standalone. But when loading this set on a
parallel PV server (running on N nodes), the number of cells in the
loaded datasets ends up being N, and the number of points becomes N *
55296. Looking at the Scalar Process Id values it seems the set is
indeed duplicated on all render nodes.
Is the use of Xdmf not supported for parallel PV?
This happens with both PV 3.8.1 and 3.10.1, btw.
Best regards,
Paul
?xml version=1.0?
Xdmf
Domain
Grid GridType=Uniform Name=Neurons-0
Topology NodesPerElement=55296 TopologyType=Polyvertex/
Geometry GeometryType=XYZ
DataItem DataType=Float Dimensions=55296 3 Format=HDF
Name=Coordinates Precision=4out.hdf5:/positions/DataItem
/Geometry
Attribute Center=Node Name=voltage Type=Scalar
DataItem DataType=Float Dimensions=55296 1 Format=HDF
Precision=4out.hdf5:/voltages/DataItem
/Attribute
Attribute Center=Node Name=type Type=Scalar
DataItem DataType=Int Dimensions=55296 1
Format=HDFout.hdf5:/types/DataItem
/Attribute
Attribute Center=Node Name=rotation Type=Vector
DataItem DataType=Float Dimensions=55296 3
Format=HDFout.hdf5:/rotations/DataItem
/Attribute
/Grid
/Domain
/Xdmf
HDF5 out.hdf5 {
GROUP / {
DATASET cells {
DATATYPE H5T_STD_I32LE
DATASPACE SIMPLE { ( 55296, 1 ) / ( 55296, 1 ) }
}
DATASET positions {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 55296, 3 ) / ( 55296, 3 ) }
}
DATASET rotations {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 55296, 3 ) / ( 55296, 3 ) }
}
DATASET types {
DATATYPE H5T_STD_I32LE
DATASPACE SIMPLE { ( 55296, 1 ) / ( 55296, 1 ) }
}
DATASET voltages {
DATATYPE H5T_IEEE_F32LE
DATASPACE SIMPLE { ( 55296, 1 ) / ( 55296, 1 ) }
}
}
}
___
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
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Xdmf data duplication
On 08/15/2011 04:17 PM, Paul Melis wrote: With a dataset stored in Xdmf I get an interesing data duplication result. The set consists of 55296 points, each with associated scalar and vector values. See below for the XML file and HDF5 layout. [...] ?xml version=1.0? Xdmf Domain Grid GridType=Uniform Name=Neurons-0 Topology NodesPerElement=55296 TopologyType=Polyvertex/ Hmmm, I seem to have the Topology tag not completely correct, NodesPerElement should be NumberOfElements. With that correction I get at least the same number of cells as number of points. This makes me wonder about the other attributes I used in the .xmf file. The data duplication issue remains, though. Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.10.1 - compile error w.r.t. MapReduceMPI
Hello Robert, On 08/05/2011 04:53 PM, Robert Maynard wrote: I have seen this problem before you need to fix the MPI_INCLUDE_PATH to only point to the directory that has mpi.h not both of those directories. If this fixes the problem you should open a bug on http://paraview.org/Bug http://paraview.org/Bug/my_view_page.php Indeed, adjusting MPI_INCLUDE_PATH fixes the build. I added a bug report, http://paraview.org/Bug/view.php?id=12485 Thanks! Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] PV 3.10.1 - compile error w.r.t. MapReduceMPI
Hi, I'm building PV 3.8.1 and PV 3.10.1 on exactly the same Debian 6.0 system (64-bit) system using the exact same CMAKE configuration lines: #!/bin/sh cmake \ -DCMAKE_BUILD_TYPE=Release \ -DMANTA_BUILD=$HOME/c/manta-2439-build \ -DMANTA_SOURCE=$HOME/c/manta-2439 \ -DPARAVIEW_BUILD_PLUGIN_Manta=ON \ -DPARAVIEW_ENABLE_PYTHON=ON \ -DPARAVIEW_USE_MPI=ON \ source-dir The 3.8.1 build succeeds, but the 3.10.1 buid fails because mpi.h is not being found: [ 4%] Built target ProcessShader [ 4%] Built target vtkMaterialLibraryConfiguredFiles [ 5%] Built target vtkproj4 [ 5%] Built target lproj [ 5%] Building CXX object VTK/Utilities/mrmpi/src/CMakeFiles/MapReduceMPI.dir/mapreduce.cpp.o /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:14:17: error: mpi.h: No such file or directory In file included from /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:22: /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:38: error: field ‘MPI_Comm’ has incomplete type /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:81: error: ‘MPI_Comm’ does not name a type /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:93: error: ‘MPI_Comm’ does not name a type In file included from /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:23: /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/keyvalue.h:36: error: field ‘MPI_Comm’ has incomplete type The relevant CMAKE MPI variables seem to be set correctly: opti@optihd0:~/c/paraview-3101-release$ grep ^MPI_ CMakeCache.txt MPI_COMPILER:FILEPATH=/usr/bin/mpic++ MPI_COMPILE_FLAGS:STRING= MPI_EXTRA_LIBRARY:STRING=/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-rte.so;/usr/lib/openmpi/lib/libopen-pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so MPI_INCLUDE_PATH:STRING=/usr/lib/openmpi/include;/usr/lib/openmpi/include/openmpi MPI_LIBRARY:FILEPATH=/usr/lib/openmpi/lib/libmpi_cxx.so MPI_LINK_FLAGS:STRING=-Wl,--export-dynamic MPI_COMPILER-ADVANCED:INTERNAL=1 MPI_COMPILE_FLAGS-ADVANCED:INTERNAL=1 MPI_EXTRA_LIBRARY-ADVANCED:INTERNAL=0 MPI_INCLUDE_PATH-ADVANCED:INTERNAL=0 MPI_LIB:INTERNAL=MPI_LIB-NOTFOUND MPI_LIBRARY-ADVANCED:INTERNAL=0 MPI_LINK_FLAGS-ADVANCED:INTERNAL=1 opti@optihd0:~/c/paraview-3101-release$ find /usr/lib -name mpi.h /usr/lib/openmpi/include/mpi.h The MPI related cache variables seem to be almost the same between 3.8 and 3.10, and in the differences I see nothing related to missing include paths or something like that: opti@optihd0:~/c/paraview-3101-release$ grep MPI_ CMakeCache.txt mpi310.txt opti@optihd0:~/c/paraview-3101-release$ grep MPI_ ../paraview-381-release/CMakeCache.txt mpi38.txt opti@optihd0:~/c/paraview-3101-release$ diff -u mpi38.txt mpi310.txt --- mpi38.txt 2011-08-05 14:13:28.781521205 +0200 +++ mpi310.txt 2011-08-05 14:13:24.305022071 +0200 @@ -1,3 +1,4 @@ +IceTMPI_LIB_DEPENDS:STATIC=general;m;general;IceTCore;general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen-rte.so;general;/usr/lib/openmpi/lib/libopen-pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so; MPI_COMPILER:FILEPATH=/usr/bin/mpic++ MPI_COMPILE_FLAGS:STRING= MPI_EXTRA_LIBRARY:STRING=/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-rte.so;/usr/lib/openmpi/lib/libopen-pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so @@ -15,12 +16,8 @@ ICET_MPI_MAX_NUMPROCS-ADVANCED:INTERNAL=1 //This is set from VTK_MPI_MAX_NUMPROCS. ICET_MPI_MAX_NUMPROCS:INTERNAL=2 -//ADVANCED property for variable: ICET_MPI_POSTFLAGS -ICET_MPI_POSTFLAGS-ADVANCED:INTERNAL=1 //This is set from VTK_MPI_POSTFLAGS. ICET_MPI_POSTFLAGS:INTERNAL= -//ADVANCED property for variable: ICET_MPI_PREFLAGS -ICET_MPI_PREFLAGS-ADVANCED:INTERNAL=1 //This is set from a combination of VTK_MPI_PREFLAGS VTK_MPI_NUMPROC_FLAG // VTK_MPI_MAX_NUMPROCS VTK_MPI_PREFLAGS. ICET_MPI_PREFLAGS:INTERNAL=;-np;2; Any clues? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.10.1 - compile error w.r.t. MapReduceMPI
Hi David, On 08/05/2011 02:55 PM, David Partyka wrote: Have you turned MPI On then Off and then back On again? I've seen it get confused when this happens. Tried that, doesn't help, unfortunately Can you try a fresh (delete your build tree) build of 3.10.1 and turn everything on at once? A fresh build in a clean build directory (together with the cmake line below) doesn't solve the problem. Note that I'm not setting the openmpi header/library locations directly, but let CMake detect them. I assume that's not a problem? Regards, Paul On Fri, Aug 5, 2011 at 8:15 AM, Paul Melis paul.me...@sara.nl mailto:paul.me...@sara.nl wrote: Hi, I'm building PV 3.8.1 and PV 3.10.1 on exactly the same Debian 6.0 system (64-bit) system using the exact same CMAKE configuration lines: #!/bin/sh cmake \ -DCMAKE_BUILD_TYPE=Release \ -DMANTA_BUILD=$HOME/c/manta-2439-build \ -DMANTA_SOURCE=$HOME/c/manta-2439 \ -DPARAVIEW_BUILD_PLUGIN_Manta=ON \ -DPARAVIEW_ENABLE_PYTHON=ON \ -DPARAVIEW_USE_MPI=ON \ source-dir The 3.8.1 build succeeds, but the 3.10.1 buid fails because mpi.h is not being found: [ 4%] Built target ProcessShader [ 4%] Built target vtkMaterialLibraryConfiguredFiles [ 5%] Built target vtkproj4 [ 5%] Built target lproj [ 5%] Building CXX object VTK/Utilities/mrmpi/src/CMakeFiles/MapReduceMPI.dir/mapreduce.cpp.o /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:14:17: error: mpi.h: No such file or directory In file included from /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:22: /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:38: error: field ‘MPI_Comm’ has incomplete type /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:81: error: ‘MPI_Comm’ does not name a type /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:93: error: ‘MPI_Comm’ does not name a type In file included from /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:23: /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/keyvalue.h:36: error: field ‘MPI_Comm’ has incomplete type The relevant CMAKE MPI variables seem to be set correctly: opti@optihd0:~/c/paraview-3101-release$ grep ^MPI_ CMakeCache.txt MPI_COMPILER:FILEPATH=/usr/bin/mpic++ MPI_COMPILE_FLAGS:STRING= MPI_EXTRA_LIBRARY:STRING=/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-rte.so;/usr/lib/openmpi/lib/libopen-pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so MPI_INCLUDE_PATH:STRING=/usr/lib/openmpi/include;/usr/lib/openmpi/include/openmpi MPI_LIBRARY:FILEPATH=/usr/lib/openmpi/lib/libmpi_cxx.so MPI_LINK_FLAGS:STRING=-Wl,--export-dynamic MPI_COMPILER-ADVANCED:INTERNAL=1 MPI_COMPILE_FLAGS-ADVANCED:INTERNAL=1 MPI_EXTRA_LIBRARY-ADVANCED:INTERNAL=0 MPI_INCLUDE_PATH-ADVANCED:INTERNAL=0 MPI_LIB:INTERNAL=MPI_LIB-NOTFOUND MPI_LIBRARY-ADVANCED:INTERNAL=0 MPI_LINK_FLAGS-ADVANCED:INTERNAL=1 opti@optihd0:~/c/paraview-3101-release$ find /usr/lib -name mpi.h /usr/lib/openmpi/include/mpi.h The MPI related cache variables seem to be almost the same between 3.8 and 3.10, and in the differences I see nothing related to missing include paths or something like that: opti@optihd0:~/c/paraview-3101-release$ grep MPI_ CMakeCache.txt mpi310.txt opti@optihd0:~/c/paraview-3101-release$ grep MPI_ ../paraview-381-release/CMakeCache.txt mpi38.txt opti@optihd0:~/c/paraview-3101-release$ diff -u mpi38.txt mpi310.txt --- mpi38.txt 2011-08-05 14:13:28.781521205 +0200 +++ mpi310.txt 2011-08-05 14:13:24.305022071 +0200 @@ -1,3 +1,4 @@ +IceTMPI_LIB_DEPENDS:STATIC=general;m;general;IceTCore;general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen-rte.so;general;/usr/lib/openmpi/lib/libopen-pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so; MPI_COMPILER:FILEPATH=/usr/bin/mpic++ MPI_COMPILE_FLAGS:STRING= MPI_EXTRA_LIBRARY:STRING=/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-rte.so;/usr/lib/openmpi/lib/libopen-pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so @@ -15,12 +16,8 @@ ICET_MPI_MAX_NUMPROCS-ADVANCED:INTERNAL=1 //This is set from VTK_MPI_MAX_NUMPROCS. ICET_MPI_MAX_NUMPROCS:INTERNAL=2 -//ADVANCED property for variable: ICET_MPI_POSTFLAGS -ICET_MPI_POSTFLAGS-ADVANCED:INTERNAL=1 //This is set from VTK_MPI_POSTFLAGS. ICET_MPI_POSTFLAGS:INTERNAL= -//ADVANCED property for variable: ICET_MPI_PREFLAGS
Re: [Paraview] PV 3.10.1 - compile error w.r.t. MapReduceMPI
Hi, I just noticed my cmake is 2.8.2, would trying the latest version help here? Paul On 08/05/2011 04:47 PM, Paul Melis wrote: Hi David, On 08/05/2011 02:55 PM, David Partyka wrote: Have you turned MPI On then Off and then back On again? I've seen it get confused when this happens. Tried that, doesn't help, unfortunately Can you try a fresh (delete your build tree) build of 3.10.1 and turn everything on at once? A fresh build in a clean build directory (together with the cmake line below) doesn't solve the problem. Note that I'm not setting the openmpi header/library locations directly, but let CMake detect them. I assume that's not a problem? Regards, Paul On Fri, Aug 5, 2011 at 8:15 AM, Paul Melis paul.me...@sara.nl mailto:paul.me...@sara.nl wrote: Hi, I'm building PV 3.8.1 and PV 3.10.1 on exactly the same Debian 6.0 system (64-bit) system using the exact same CMAKE configuration lines: #!/bin/sh cmake \ -DCMAKE_BUILD_TYPE=Release \ -DMANTA_BUILD=$HOME/c/manta-2439-build \ -DMANTA_SOURCE=$HOME/c/manta-2439 \ -DPARAVIEW_BUILD_PLUGIN_Manta=ON \ -DPARAVIEW_ENABLE_PYTHON=ON \ -DPARAVIEW_USE_MPI=ON \ source-dir The 3.8.1 build succeeds, but the 3.10.1 buid fails because mpi.h is not being found: [ 4%] Built target ProcessShader [ 4%] Built target vtkMaterialLibraryConfiguredFiles [ 5%] Built target vtkproj4 [ 5%] Built target lproj [ 5%] Building CXX object VTK/Utilities/mrmpi/src/CMakeFiles/MapReduceMPI.dir/mapreduce.cpp.o /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:14:17: error: mpi.h: No such file or directory In file included from /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:22: /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:38: error: field ‘MPI_Comm’ has incomplete type /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:81: error: ‘MPI_Comm’ does not name a type /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.h:93: error: ‘MPI_Comm’ does not name a type In file included from /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/mapreduce.cpp:23: /home/opti/c/ParaView-3.10.1/VTK/Utilities/mrmpi/src/keyvalue.h:36: error: field ‘MPI_Comm’ has incomplete type The relevant CMAKE MPI variables seem to be set correctly: opti@optihd0:~/c/paraview-3101-release$ grep ^MPI_ CMakeCache.txt MPI_COMPILER:FILEPATH=/usr/bin/mpic++ MPI_COMPILE_FLAGS:STRING= MPI_EXTRA_LIBRARY:STRING=/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-rte.so;/usr/lib/openmpi/lib/libopen-pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so MPI_INCLUDE_PATH:STRING=/usr/lib/openmpi/include;/usr/lib/openmpi/include/openmpi MPI_LIBRARY:FILEPATH=/usr/lib/openmpi/lib/libmpi_cxx.so MPI_LINK_FLAGS:STRING=-Wl,--export-dynamic MPI_COMPILER-ADVANCED:INTERNAL=1 MPI_COMPILE_FLAGS-ADVANCED:INTERNAL=1 MPI_EXTRA_LIBRARY-ADVANCED:INTERNAL=0 MPI_INCLUDE_PATH-ADVANCED:INTERNAL=0 MPI_LIB:INTERNAL=MPI_LIB-NOTFOUND MPI_LIBRARY-ADVANCED:INTERNAL=0 MPI_LINK_FLAGS-ADVANCED:INTERNAL=1 opti@optihd0:~/c/paraview-3101-release$ find /usr/lib -name mpi.h /usr/lib/openmpi/include/mpi.h The MPI related cache variables seem to be almost the same between 3.8 and 3.10, and in the differences I see nothing related to missing include paths or something like that: opti@optihd0:~/c/paraview-3101-release$ grep MPI_ CMakeCache.txt mpi310.txt opti@optihd0:~/c/paraview-3101-release$ grep MPI_ ../paraview-381-release/CMakeCache.txt mpi38.txt opti@optihd0:~/c/paraview-3101-release$ diff -u mpi38.txt mpi310.txt --- mpi38.txt 2011-08-05 14:13:28.781521205 +0200 +++ mpi310.txt 2011-08-05 14:13:24.305022071 +0200 @@ -1,3 +1,4 @@ +IceTMPI_LIB_DEPENDS:STATIC=general;m;general;IceTCore;general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen-rte.so;general;/usr/lib/openmpi/lib/libopen-pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so; MPI_COMPILER:FILEPATH=/usr/bin/mpic++ MPI_COMPILE_FLAGS:STRING= MPI_EXTRA_LIBRARY:STRING=/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen-rte.so;/usr/lib/openmpi/lib/libopen-pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so @@ -15,12 +16,8 @@ ICET_MPI_MAX_NUMPROCS-ADVANCED:INTERNAL=1 //This is set from VTK_MPI_MAX_NUMPROCS. ICET_MPI_MAX_NUMPROCS:INTERNAL=2 -//ADVANCED property for variable: ICET_MPI_POSTFLAGS -ICET_MPI_POSTFLAGS-ADVANCED:INTERNAL=1
Re: [Paraview] PV 3.10.1 - compile error w.r.t. MapReduceMPI
On 08/05/2011 04:53 PM, David Partyka wrote: Yeah, FindMPI has recently been re-written I would update to the latest and give that a shot. With cmake 2.8.5 I get the following warning more than once during cmake configure: CMake Warning (dev) at /home/opti/software/cmake285/share/cmake-2.8/Modules/FindMPI.cmake:81 (include): File /home/opti/software/cmake285/share/cmake-2.8/Modules/FindMPI.cmake includes /home/opti/c/ParaView-3.10.1/CMake/GetPrerequisites.cmake (found via CMAKE_MODULE_PATH) which shadows /home/opti/software/cmake285/share/cmake-2.8/Modules/GetPrerequisites.cmake. This may cause errors later on . Policy CMP0017 is not set: Prefer files from the CMake module directory when including from there. Run cmake --help-policy CMP0017 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): VTK/CMakeLists.txt:876 (FIND_PACKAGE) This warning is for project developers. Use -Wno-dev to suppress it. Furthermore, the mpi.h not found error is still there ... :-/ Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Off Screen Rendering
Hi, This is an old post, to which I replied at the time, but now that I'm rereading it I'm wondering whether the summary below was correct? On 11/26/2009 07:50 AM, chew ping wrote: so based on the timer log results that i collected, what i read about offscreen-rendering and the explanation below, can i conclude the followings? someone pls correct me if i'm wrong! with --use-offscreen-rendering * X windows are disabled on all server processes * all server processes render the geometry locally * then each server processes sends the image to the client for compositing * there's NO data gathering to process 0, meaning the master doesn't collect all images from each processes for composting, then only send it to the client for rendering Assuming a non-Mesa version of Paraview that is run with --offscreen-rendering what happens w.r.t. compositing? Are the images rendered by the pvserver processes indeed sent to the *client* for compositing? Or is process 0 responsible for compositing, followed by forwarding the final image to the client? * that's why --use-offscreen-rendering is faster without --use-offscreen-rendering * X windows are enabled on all server processes * all server processes the raw data, then send all geometry to process 0 * process 0 gather all geometry then send them to the client to render * the client does all the rendering job Why would the client do all the rendering in this case? Assuming an amount of data over the local rendering threshold why would the pvserver's not each render their part and send out images for compositing? What has the choice of offscreen/non-offscreen rendering to do with it? Thanks, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Shortcut for toggling orthographic projection?
Hi David, Thanks for the tip. I just noticed the little Edit View Options button just above a view and that also gives quick(er) access to the projection setting. Regards, Paul On 03/25/2011 06:53 PM, David E DeMarle wrote: Does python trace capture that? If so, you can make a macro for each direction quite easily. David E DeMarle Kitware, Inc. RD Engineer 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-371-3971 x109 On Thu, Mar 24, 2011 at 11:24 AM, Paul Melis paul.me...@sara.nl mailto:paul.me...@sara.nl wrote: Hi, Is there in PV (3.8 / 3.10) a quick way to switch between orthographic and perspective projection? The only method I see is going through the menu (Edit - View settings - General - Use Parallel Projection). Thanks, Paul ___ Powered by www.kitware.com http://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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Make install fails
Hi, With a freshly built PV 3.8.1 with CMake 2.8.4 I get (see attachement for full log) this with make install: [...] -- Installing: /home/opti/software/pv381reldebinfo/lib/paraview-3.8/purple-2/perl -- Installing: /home/opti/software/pv381reldebinfo/lib/paraview-3.8/purple-2/perl/auto -- Installing: /home/opti/software/pv381reldebinfo/lib/paraview-3.8/purple-2/perl/auto/Purple -- Installing: /home/opti/software/pv381reldebinfo/lib/paraview-3.8/gstreamer0.10 -- Installing: /home/opti/software/pv381reldebinfo/lib/paraview-3.8/gstreamer0.10/gstreamer-0.10 -- Installing: /home/opti/software/pv381reldebinfo/lib/paraview-3.8/paraview -- Installing: /home/opti/software/pv381reldebinfo/lib/paraview-3.8/paraview/paraview CMake Error at Applications/ParaView/cmake_install.cmake:70 (FILE): file INSTALL cannot make directory /home/opti/software/pv381reldebinfo/lib/paraview-3.8/paraview/paraview: Not a directory Call Stack (most recent call first): Applications/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:49 (INCLUDE) make: *** [install] Error 1 The reason installation fails is that /home/opti/software/pv381reldebinfo/lib/paraview-3.8/paraview/paraview is already present as a file (2,052,666 bytes). I've found several installation issues on the list, but none like this. I also wonder why all kinds of Paraview-unrelated stuff is in the output (see full log, e.g. totem, open office, mono, vlc, xulrunner, ...). It's almost like all installed packages on the system get somehow represented in the PV lib/paraview-3.8 directory. Something like that might explain the clash, as a system-wide PV 3.4.0 is also installed, from the normal Ubunty package repo. Perhaps relevant build options: BUILD_SHARED_LIBS=ON CMAKE_BUILD_TYPE=RelWithDebInfo PARAVIEW_BUILD_QT_GUI=ON PARAVIEW_ENABLE_PYTHON=ON PARAVIEW_USE_MPI=OFF Other info: Ubuntu 10.04.2 x86_64 GCC 4.4.3 CMake 2.8.4 (built from source, no system cmake installed). Regards, Paul pv.txt.gz Description: GNU Zip compressed data ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Shortcut for toggling orthographic projection?
Hi, Is there in PV (3.8 / 3.10) a quick way to switch between orthographic and perspective projection? The only method I see is going through the menu (Edit - View settings - General - Use Parallel Projection). Thanks, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Parallel image data, pieces stored as PNG?
Dear all, Is it possible to use one of the parallel file formats to read in a 3D image data set from a set of 2D slices, where the slice images remain in a standard image format (e.g. PNG, JPEG)? Concretely, I have a set of slices in PNG format and want to visualize/process the volume they define in parallel, i.e. using multiple pvserver processes on a cluster. I was hoping to avoid having to convert the slice images to a VTK format, but from reading the VTK file formats docs it seems this is necessary. I tried referencing them from a .pvti file as pieces stored in PNG files, but this doesn't seem to work. Is converting the slices to VTK (e.g. .vti) the only way? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] .cosmo file format?
Hi, Is there some documentation on the file format Cosmology files (.cosmo) supported in PV? I've been reading Analyzing and visualizing cosmological simulations with paraview by Woodring et.al, where the cosmological support that was added to PV 3.8 is described. The .cosmo file format is mentioned, but the given reference where it is supposedly introduced doesn't mention it at all. Reading the parallel .cosmo reader and related source files doesn't give me a clearer picture either. Thanks, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] PV3.8 RC1: Ctrl+O no longer works
Hi, After starting a fresh PV3.8RC1 and pressing Ctrl+O to get started, I get: QAction::eventFilter: ambiguous shortcut overload: Ctrl+O ... and no file open dialog. Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV3.8 RC1: Ctrl+O no longer works
Felipe Bordeu Weldt wrote: I'm using PV3.8RC1 for Mac and everything work fine. are you using the linux or windows version ??? Oops, forgot the platform details. It's on 32-bit Linux, with PV 3.8 RC1 compiled against Qt 4.6.2 (the SDK version). Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] PV 3.8 RC1 + Cmake 2.8.1 failing?
Hi, I previously built PV 3.8 RC1 with cmake 2.6.4 successfully. I've now switched to cmake 2.8.1 and compilation succeeds 99.9% :) [...] Scanning dependencies of target NIfTIWriter [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/qrc_NIfTIWriter.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/vtkNIfTIWriter.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/vtknifti1_io.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/vtkznzlib.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/vtkNIfTIWriterClientServer.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/vtknifti1_ioClientServer.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/vtkznzlibClientServer.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/NIfTIWriterInit.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/vtkSMNIfTIWriterInstantiator.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/NIfTIWriter_Plugin.cxx.o [100%] Building CXX object Plugins/AnalyzeNIfTIReaderWriter/CMakeFiles/NIfTIWriter.dir/moc_NIfTIWriter_Plugin.cxx.o Linking CXX shared library ../../bin/libNIfTIWriter.so [100%] Built target NIfTIWriter [100%] Generating ui_ParaViewMainWindow.h [100%] Generating qrc_paraview_generated.cxx [100%] Generating qrc_paraview_configuration.cxx make[2]: *** No rule to make target `Applications/ParaView/../../Documentation/paraview.qch', needed by `Applications/ParaView/qrc_paraview_help.cxx'. Stop. make[1]: *** [Applications/ParaView/CMakeFiles/paraview-real.dir/all] Error 2 make: *** [all] Error 2 This is using a new and empty build directory, so no previous state from cmake 2.6.4 should be involved. As this is an error in a makefile it seems this would be cmake-related? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.8 RC1 + Cmake 2.8.1 failing?
Hi Sven, Sven Buijssen wrote: That's a known issue with PV 3.8 RC1 and CVS HEAD when compiling from scratch, occurring on 64bit Linux systems, but not on 32bit Linux nor 64bit Solaris SPARC. Don't know about Mac or Windows. For completeness, this is on 32-bit Linux. It is caused by PARAVIEW_GENERATE_PROXY_DOCUMENTATION:BOOL=ON. Set it to OFF and you'll not get help for sources, filters, readers writers, but compilation will succeed. Dave is already aware of the fact and working on it. It's set to OFF already could there be another reason? (It should have nothing to do with the cmake version. When using cmake 2.6.4 you probably built incrementally, right?) Well, not the first time I built the release candidate, obviously. That was in a separate clean directory as well, and I didn't have that error. Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ParaView 3.8.0 RC1 Available for download
Hi, Dave Partyka wrote: Greetings Everyone, We have just made ParaView 3.8.0 Release Candidate 1 binaries available for download on the ParaView download page. Final binaries and/or more release candidates should follow shortly after the Git transition occurring next week. http://paraview.org/paraview/resources/software.html The release notes can be found here: http://www.kitware.com/news/home/browse/Paraview?2010_04_05ParaView+3.8 http://www.kitware.com/news/home/browse/Paraview?2010_04_05ParaView+3.8 Interesting to see a Manta plugin has been added. I can't get it to compile though, as it seems SSE isn't enabled during compilation (no -msse[2] and/or MANTA_SSE isn't defined). With the latest manta from SVN I get: [ 95%] Building CXX object Plugins/Manta/VTK/CMakeFiles/vtkManta.dir/vtkMantaActor.o cd /scratch/paulm/paraview-3.8rc1-build/Plugins/Manta/VTK /home/paulm/local/bin/c++ -DVTK_PYTHON_BUILD -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE -Wno-deprecated -Wno-deprecated -O3 -DNDEBUG -I/scratch/paulm/paraview-3.8rc1-build -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities -I/scratch/paulm/paraview-3.8rc1-build/VTK -I/scratch/paulm/paraview-3.8rc1-build/VTK/Common -I/scratch/paulm/paraview-3.8rc1-build/VTK/VolumeRendering -I/scratch/paulm/paraview-3.8rc1-build/VTK/Rendering -I/scratch/paulm/paraview-3.8rc1-build/VTK/Charts -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/vtkalglib -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Infovis -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Geovis -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Views -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Parallel -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/VolumeRendering -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Hybrid -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Widgets -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Rendering -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Charts -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Rendering/Testing/Cxx -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/IO -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Imaging -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Graphics -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/GenericFiltering -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Filtering -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Common -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Common/Testing/Cxx -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/vtklibproj4 -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/vtklibproj4 -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/DICOMParser -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/DICOMParser -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/vtkfreetype/include -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/vtkfreetype/include -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/vtknetcdf -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/vtknetcdf -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/vtkexodus2/include -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/vtkexodus2/include -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/MaterialLibrary -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/MaterialLibrary -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/verdict -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/verdict -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/Cosmo -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/Cosmo -I/scratch/paulm/paraview-3.8rc1-build/VTK/Utilities/VPIC -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/VPIC -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/utf8/source -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/GUISupport/Qt -I/scratch/paulm/paraview-3.8rc1-build/VTK/GUISupport/Qt -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/GUISupport/Qt/Chart -I/scratch/paulm/paraview-3.8rc1-build/VTK/GUISupport/Qt/Chart -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Utilities/vtkalglib -I/scratch/paulm/ParaView-3.8.0-RC1/Utilities/VTKClientServer -I/scratch/paulm/ParaView-3.8.0-RC1/Common/KWCommon -I/scratch/paulm/ParaView-3.8.0-RC1/Servers/Filters -I/scratch/paulm/ParaView-3.8.0-RC1/Servers/ServerManager -I/scratch/paulm/ParaView-3.8.0-RC1/Servers/Common -I/scratch/paulm/ParaView-3.8.0-RC1/Utilities/VTKPythonWrapping/Executable -I/scratch/paulm/ParaView-3.8.0-RC1/VTK/Wrapping -I/scratch/paulm/paraview-3.8rc1-build/VTK/Wrapping -I/scratch/paulm/paraview-3.8rc1-build/Utilities/VTKClientServer -I/scratch/paulm/paraview-3.8rc1-build/Servers/Filters -I/scratch/paulm/paraview-3.8rc1-build/Servers/ServerManager -I/scratch/paulm/paraview-3.8rc1-build/Servers/Common -I/scratch/paulm/ParaView-3.8.0-RC1/Utilities/Xdmf2/vtk -I/scratch/paulm/paraview-3.8rc1-build/Utilities/Xdmf2/vtk -I/scratch/paulm/ParaView-3.8.0-RC1/Utilities/hdf5 -I/scratch/paulm/paraview-3.8rc1-build/Utilities/hdf5 -I/scratch/paulm/manta-svn -I/scratch/paulm/manta-build/include -I/scratch/paulm/paraview-3.8rc1-build/Plugins/Manta/VTK -I/scratch/paulm/ParaView-3.8.0-RC1/Plugins/Manta/VTK -o CMakeFiles/vtkManta.dir/vtkMantaActor.o
Re: [Paraview] ParaView 3.8.0 RC1 Available for download
Dave Partyka wrote: Greetings Everyone, We have just made ParaView 3.8.0 Release Candidate 1 binaries available for download on the ParaView download page. Final binaries and/or more release candidates should follow shortly after the Git transition occurring next week. http://paraview.org/paraview/resources/software.html The release notes can be found here: http://www.kitware.com/news/home/browse/Paraview?2010_04_05ParaView+3.8 http://www.kitware.com/news/home/browse/Paraview?2010_04_05ParaView+3.8 One thing to note, there are now two sets of Mac Binaries. An App and Server Tools compiled as universal binaries that work on Tiger (10.4) or later and are built with Carbon. A new addition includes a set of App and Server Tools compiled 64-bit with Cocoa that work on Leopard (10.5) and higher only. Some of the known bugs presently include: 1. Images and portions of the integrated Documentation are missing on some platforms. 2. Intermittent crashes when closing VisTrails/ParaView after loading the VisTrails plugin. Please feel free to try them out and provide any feedback about your experiences with them. I have PARAVIEW_ENABLE_PYTHON to OFF (the default it seems as I didn't touch it) and get this compile error with PV 3.8rc1: [ 98%] Building CXX object Plugins/pvblot/CMakeFiles/pvblot.dir/PVBlotPluginActionsImplementation.cxx.o [ 98%] Building CXX object Plugins/pvblot/CMakeFiles/pvblot.dir/moc_PVBlotPluginActionsImplementation.cxx.o [ 98%] Building CXX object Plugins/pvblot/CMakeFiles/pvblot.dir/pqBlotDialog.cxx.o [ 98%] Building CXX object Plugins/pvblot/CMakeFiles/pvblot.dir/pqBlotShell.cxx.o In file included from /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:22: /scratch/paulm/ParaView-3.8.0-RC1/VTK/Common/vtkPython.h:46:22: error: Python.h: No such file or directory /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx: In member function ‘virtual void pqBlotShell::promptForInput()’: /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:227: error: ‘PyObject’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:227: error: ‘modules’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:227: error: ‘PySys_GetObject’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:228: error: ‘pvblotmodule’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:228: error: ‘PyDict_GetItemString’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:232: error: ‘pvblotdict’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:232: error: ‘PyModule_GetDict’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:235: error: ‘pvblotinterp’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:238: error: ‘promptObj’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:239: error: ‘PyObject_GetAttrString’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:240: error: ‘PyObject_Str’ was not declared in this scope /scratch/paulm/ParaView-3.8.0-RC1/Plugins/pvblot/pqBlotShell.cxx:240: error: ‘PyString_AsString’ was not declared in this scope make[2]: *** [Plugins/pvblot/CMakeFiles/pvblot.dir/pqBlotShell.cxx.o] Error 1 Should the pqBlotShell even be built in this case or should PARAVIEW_ENABLE_PYTHON not have any influence on this? I do have the python headers installed, btw. Oh, and is posting to this list the preferred way to give feedback on release candidates or would paraview-developers and/or mantis be a better place? Bye, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ParaView 3.8.0 RC1 Available for download
Hi David, David E DeMarle wrote: When you configure manta, try turning MANTA_SSE off. Right, that's what my next step turned out to be :) Costs a lot of performance though... (8.7 fps instead 18 for the standard manta demo). Then rebuild paraview and try the manta plugin. You may want to ping the manta mailing list about why SSE isn't found on your platform and why that code path in DynBVH fails when it isn't. Well, the Manta configuration *does* find SSE. It seems it's Paraview that isn't compiling against Manta in the correct way. This could be due to $MANTA_BUILD_DIR/MantaConfigure.cmake not adding any SSE-related compile flags when it should. The end result is that -msse[2] and -DMANTA_SSE are not passed to g++ when it's compiling the manta-related sources in Paraview. Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ParaView 3.8.0 RC1 Available for download
David E DeMarle wrote: When you configure manta, try turning MANTA_SSE off. Then run manta to make sure that manta itself is working. By the way, on a Vis09 presentation by Jon Woodrig, yourself and others it is mentioned that you should configure manta with MANTA_USE_X11 to OFF. Is that really needed? This causes the bin/manta executable to stop working, probably because it can't open a window or something like that. That makes it hard to test if manta itself is actually working before loading it in paraview, or is there another way for doing that test? Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ParaView 3.8.0 RC1 Available for download
David E DeMarle wrote: As far as I know you don't _need_ to turn off X11 in manta to use it in ParaView - I never do. Although I can think of reasons why it _might_ make sense to do so I am not really sure why we made that recommendation back then. Well, I finally got the plugin to work (after having to recompile PV as it hadn't shared libs enabled and therefore could not load any plugins; would it be an idea to force BUILD_SHARED_LIBS to ON whenever at least one plugin is going to be built?). I noticed there was a separate window showing the manta output a second time, but that probably isn't caused by the X11 setting? Thanks for the detailed report on the SSE config. I will fix that. Please also file a bug report on ParaView's bug tracker to help me not forget it if I get too busy to get to it today. make install also doesn't seem to copy over all the manta stuff, I'll file a separate bug for that. Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.6.2 and VirtualGL
Utkarsh Ayachit wrote: I cannot think of why this could be happening. Try playing with scalar coloring on/off etc. for the glyphs. What happens if you further process the gyphs, say pass through a shrink filter? No change, still no results. One thing I just noticed in shock is that when I use the precompiled 3.6.2 binaries from paraview.org I *do* get glyphs when using remote rendering. So this seems to be a case in which my own compiled binaries misbehave. Could this be due to using the 3.6.2 sources which require Qt 4.3, while Ubuntu 9.10 provides Qt 4.5.2? I noticed the warning during configuration, but compilation seemed to work, so didn't think much of it. [two hours later] And sure enough, after compiling Qt 4.3.5 and recompiling Paraview against it I now have working glyphs when using remote rendering... Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] PV 3.6.2 and VirtualGL
Hi, I'm experimenting with running paraview on a remote visualization server, using VirtualGL. This package basically lets you run an OpenGL application as you normally would, but intercepts the swapbuffer events to read back the framebuffer, which then gets JPEG compressed and sent to a client machine (see [1] for an excerpt from the manual). On the client side you get a normal X11 application (using X forwarding), but the 3D rendering is done on the server side and transported using a dedicated connection. When using PV 3.6.2 in this setup I get the following strange results. I have a dataset on which I apply the Glyph filter. When running PV locally (without any remote rendering) this glyphing works fine. But, when I run paraview remotely it refuses to show glyphs for the exact same dataset and same pipeline. The strange thing is that I can't get any of the glyph types to show anything, except for 2D Glyph + Vertex. For that mode I get what I expect. I've disabled depth peeling to exclude a source of possible interference. VirtualGL itself should basically leave the 3D rendering untouched, except during context creation and on swapbuffer events. Is there anything special in how Paraview draws its glyphs? Thanks, Paul [1] Whenever a window is created by the application, VirtualGL creates a corresponding 3D pixel buffer (“Pbuffer”) on a 3D graphics card in the application server. Whenever the application requests that an OpenGL rendering context be created for the window, VirtualGL intercepts the request and creates the context on the corresponding Pbuffer instead. Whenever the application swaps or flushes the drawing buffer to indicate that it has finished rendering a frame, VirtualGL reads back the Pbuffer and sends the rendered 3D image to the client. ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.6.2 and VirtualGL
Utkarsh Ayachit wrote: That's very interesting. You are seeing the issue only with glyph not with any other filter? - On a velocity field I had lying around, using the Stream Tracer displays streamlines. Trying glyphs on the same set fails. Switching to the slice representation works. - Volume rendering works for the iron protein sample file, as well as displaying output of a Contour filter. Saving the geometry and loading it back in also displays it correctly. - A simple Sphere source followed by e.g. Subdivide and Smooth works. Showing the result in wireframe, points, etc. all works. - From the PV sample data: policital.vtk shows the line map - Glyphing doesn't work on multiple sets I tried, except for 2D vertex glyphs. Glyph with Custom Source and e.g. a sphere source also doesn't work. So, it seems it's basically glyping that fails... I am wondering if you can show two 3D geometries at the same time and does that work? Do you mean adding a Glyph filter twice, one set to e.g. Spheres, the other to 2D vertex? If so, then this only shows the 2D vertices Paul On Wed, Mar 3, 2010 at 7:27 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm experimenting with running paraview on a remote visualization server, using VirtualGL. This package basically lets you run an OpenGL application as you normally would, but intercepts the swapbuffer events to read back the framebuffer, which then gets JPEG compressed and sent to a client machine (see [1] for an excerpt from the manual). On the client side you get a normal X11 application (using X forwarding), but the 3D rendering is done on the server side and transported using a dedicated connection. When using PV 3.6.2 in this setup I get the following strange results. I have a dataset on which I apply the Glyph filter. When running PV locally (without any remote rendering) this glyphing works fine. But, when I run paraview remotely it refuses to show glyphs for the exact same dataset and same pipeline. The strange thing is that I can't get any of the glyph types to show anything, except for 2D Glyph + Vertex. For that mode I get what I expect. I've disabled depth peeling to exclude a source of possible interference. VirtualGL itself should basically leave the 3D rendering untouched, except during context creation and on swapbuffer events. Is there anything special in how Paraview draws its glyphs? Thanks, Paul [1] Whenever a window is created by the application, VirtualGL creates a corresponding 3D pixel buffer (“Pbuffer”) on a 3D graphics card in the application server. Whenever the application requests that an OpenGL rendering context be created for the window, VirtualGL intercepts the request and creates the context on the corresponding Pbuffer instead. Whenever the application swaps or flushes the drawing buffer to indicate that it has finished rendering a frame, VirtualGL reads back the Pbuffer and sends the rendered 3D image to the client. ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.6.2 and VirtualGL
Utkarsh Ayachit wrote: Do you mean adding a Glyph filter twice, one set to e.g. Spheres, the other to 2D vertex? If so, then this only shows the 2D vertices I meant simply try creating two sphere sources (with different centers). Do both of them show up correctly? Yes, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Off Screen Rendering
Hi Ken, How does Paraview's tiled panel display support fit into this? Am I right in assuming that in that case (without offscreen-rendering) the pvservers send image output to the client, where a composited image is displayed? Or is the client also doing local rendering of geometry sent to it from the servers? Regards, Paul From: paraview-boun...@paraview.org [paraview-boun...@paraview.org] On Behalf Of Moreland, Kenneth [kmo...@sandia.gov] Sent: Monday, November 30, 2009 7:20 PM To: chew ping; weaponfire2...@163.com Cc: paraview Subject: Re: [Paraview] Off Screen Rendering That is correct with two clarifications: The “with ―use-offscreen-rendering” explanation is only correct for when ParaView is compiled with OSMesa. The “without ―use-offscreen-rendering” behavior only happens because the servers try to open X windows and fail. -Ken On 11/25/09 11:50 PM, chew ping lcp8...@msn.com wrote: Dear all, so based on the timer log results that i collected, what i read about offscreen-rendering and the explanation below, can i conclude the followings? someone pls correct me if i'm wrong! with --use-offscreen-rendering * X windows are disabled on all server processes * all server processes render the geometry locally * then each server processes sends the image to the client for compositing * there's NO data gathering to process 0, meaning the master doesn't collect all images from each processes for composting, then only send it to the client for rendering * that's why --use-offscreen-rendering is faster without --use-offscreen-rendering * X windows are enabled on all server processes * all server processes the raw data, then send all geometry to process 0 * process 0 gather all geometry then send them to the client to render * the client does all the rendering job * that's why without --use-offscreen-rendering is slower any help / reply is highly appreciated Best Regards, chewping Date: Fri, 20 Nov 2009 10:57:25 +0800 From: weaponfire2...@163.com To: lcp8...@msn.com CC: paraview@paraview.org Subject: Re:[Paraview] Off Screen Rendering hi chew ping： The Problem:Display is not accessible on the server side. Remote rendering will be disabled., it means that not all server start up X Server, so the server will process the raw data and send all geometry to the client to render. The client do all the rendering job, that's the reason why case 2 is so slow, I think. When you use off screen, all server processes render the geometry locally , send image to client to composite, so case 1 much faster than case 2. I hope this can help you, for I got the same problem before. Good luck. 在2009-11-20，chew ping lcp8...@msn.com 写道： Dear all, i'm doing parallel rendering using 2 machines (np4), i notice an obvious difference between using offscreen-rendering (faster) and without offscreen-rendering (much slower). i realize this from the timer log: Case 1: with offscreen-rendering -- Local Process Still Render, 0.666444 seconds Execute vtkMPIMoveData id: 519, 0.000199 seconds Execute vtkPolyDataMapper id: 311, 0.000106 seconds Server, Process 0 Execute vtkFileSeriesReader id: 238, 0.645881 seconds Execute vtkPVGeometryFilter id: 305, 0.005891 seconds Execute vtkPVCacheKeeper id: 516, 7.8e-05 seconds Execute vtkMPIMoveData id: 519, 0.000212 seconds Execute vtkOrderedCompositeDistributor , 0.000152 seconds Execute vtkPolyDataMapper id: 311 , 0.000274 seconds Server, Process 1 Execute vtkFileSeriesReader id: 238, 0.000275 seconds Execute vtkPVGeometryFilter id: 305, 0.005299 seconds Execute vtkPVCacheKeeper id: 516, 7.7e-05 seconds Execute vtkMPIMoveData id: 519, 0.000147 seconds Execute vtkOrderedCompositeDistributor , 0.000117 seconds Execute vtkPolyDataMapper id: 311, 9.9e-05 seconds Server, Process 2 Execute vtkFileSeriesReader id: 238, 0.000258 seconds Execute vtkPVGeometryFilter id: 305, 0.004765 seconds Execute vtkPVCacheKeeper id: 516, 7.7e-05 seconds Execute vtkMPIMoveData id: 519, 0.000147 seconds Execute vtkOrderedCompositeDistributor , 0.000111 seconds Execute vtkPolyDataMapper id: 311, 9.5e-05 seconds Server, Process 3 Execute vtkFileSeriesReader id: 238, 0.000352 seconds Execute vtkPVGeometryFilter id: 305, 0.005351 seconds Execute vtkPVCacheKeeper id: 516, 7.7e-05 seconds Execute vtkMPIMoveData id: 519, 0.00016 8 seconds Execute vtkOrderedCompositeDistributor , 0.000111 seconds Execute vtkPolyDataMapper id: 311, 0.000108 seconds --- Case 2: without offscreen-rendering --- Local Process Still Render, 4.86495 seconds Execute vtkMPIMoveData id: 520, 2.81566 seconds Execute vtkPolyDataMapper id: 312, 0.00012 seconds Execute vtkPolyDataMapper id: 148, 7.6e-05 seconds Server,
Re: [Paraview] Tiled display
Greg Abram wrote: We have a 15x5 tiled display, and I'm thinking about running to the whole thing. If you do, can you keep us informed if you run into http://public.kitware.com/Bug/view.php?id=8464 ? If not, I'd be very interested to know how your setup differs from mine, as it seems that that bug basically makes Paraview's current TPD support unusable. Regards, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Dual-headed output from a single GPU?
Paul Melis wrote: The first thing that's off is that although I get undecorated Paraview render areas on each panel display they don't fill the whole screen (only roughly 75% in both width and height). I did some more testing using a different setup (3 displays, vertically stacked). I noticed the following things: * After connecting with the paraview GUI to the server all displays render fullscreen. The axes are shown on the blue background in the right position and I can move them around over the different displays * When I add some element to the scene it depends on the type of element what happens. For example, if I add a cone source all 3 displays change size. I haven't measured exactly but the size they end up using seems to be the same as *the size of the render area in the GUI*. Trying different window sizes for the GUI (after restarting everything) shows a pretty strong correlation between GUI render area size and display render area size. If, after restarting everything, I add a mandelbrot source to the scene the panel render areas size stays the same, i.e. fullscreen. Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] pvserver --help text
Hello, pvserver --help reports: --use-offscreen-rendering Render offscreen on the satellite processes. This option only works with software rendering or mangled mesa on Unix. Is this true? Is there no way to get offscreen hardware-accelerated rendering in Paraview other than compiling with Mangled Mesa? Or is the help text bogus? Regards Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Dual-headed output from a single GPU?
Hello, Paul Melis wrote: Berk Geveci wrote: Yeah, unfortunately it is hard for us to provide binaries with MPI support because MPI is implemented with different (internal) APIs by different vendors. We would have to create a different binary for each MPI distribution. No problem, building paraview isn't really difficult and so I now have an mpi-enabled version that seems to do the trick. Or so I thought... Just to summarize my configuration: * I'm using (for now) a single render node with a single GPU, but dual-headed output * X is configured to run one server, with two screens (:0.0 en :0.1) * I'm running pvserver with mpirun -bynode -np 1 ./pvserver -tdx=2 -tdy=1 -display :0.0 : -np 1 ./pvserver -tdx=2 -tdy=1 -display :0.1 * I'm running the GUI from a different system through an SSH tunnel to port 1 on the render node * I'm using paraview 3.6.1 on 32-bit Ubuntu Linux boxes The first thing that's off is that although I get undecorated Paraview render areas on each panel display they don't fill the whole screen (only roughly 75% in both width and height). Secondly, when loading a dataset and e.g. extracting an isosurface the rendering seems to work fine (minus the not completely full-screen render area). I can also see the two display match up nicely (I haven't specified any mullion setting so I'm assuming they get set to zero pixels). So far so good. But when I switch to volume rendering I get the strange artifact that each display renders only half of the total volume set; the left display only does the upper half, the right only the lower half. Even when the complete volume is moved so it is fully shown on only one display only half of the set is rendered. This seems to suggest that there is some kind of sort-last rendering going on, instead of sort-first. Any clues? Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Dual-headed output from a single GPU?
Hi, I'm trying to get paraview to handle rendering on a single GPU with dual-monitor outputs. These outputs are run using different X screens on the same X server. Using xinerama is not an option as this is a preliminary test setup for driving a TPD using nodes that each drive 2 displays and the mullions can't be handled correctly with xinerama. The goal is to run Paraview as described in https://visualization.hpc.mil/wiki/Paraview_Tiled-Display_Mode. The problem I have is to get multiple pvservers to run on the same host. I'm basically following the procedure outlined in Multiple GPUs Per Node on http://www.itk.org/Wiki/Setting_up_a_ParaView_Server. The -bynode mpirun line (supported by OpenMPI) works, but it leads to the different pvserver processes trying to listen on port 1: pa...@sara0143:/scratch/paulm/paraview-3.6.1-Linux-i686/bin$ mpirun -bynode -np 1 ./pvserver -display :0.0 : -np 1 ./pvserver -display :0.1 Listen on port: 1 Waiting for client... Listen on port: 1 ERROR: In /home/kitware/ParaView-3.6/ParaView3/Servers/Common/vtkProcessModuleConnectionManager.cxx, line 193 vtkProcessModuleConnectionManager (0x8216f60): Failed to set up server socket. As far as I understand it this port (1) is the combined server port that the client connects to, but the connections among different pvservers will use different (arbitrary) ports. So it seems two pvservers want to play the role of combined server entry point in my case. The mpirun line above is very similar to the one shown in the Setting_up_a_ParaView_Server wiki page: mpirun -bynode -np 8 ./pvserver -display :0.0 : -np 8 ./pvserver -display :0.1 Is there some information missing on that page that is needed to get this specific setup to work? I.e. something in an MPI hosts file? Thanks in advance, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Dual-headed output from a single GPU?
Berk Geveci wrote: You shouldn't have to do anything special. I am not an OpenMPI expert so I can't speak to the MPI configurations. When you run pvserver with MPI, only the first node will listen to the server port. The others should wait for the first node in an MPI receive call. The fact that both servers are trying to listen to that port tells me that either ParaView is not compile with MPI or there is something wrong with the way you are using mpirun. To verify which one is the case, try mpirun -np 2 ./pvserver. If they are both trying to grab port 1, ParaView is not compiled with MPI. Otherwise, something is wrong with the MPI line you are using. Ah, interesting detail :) I grabbed the precompiled version from paraview.org but now see that it doesn't include MPI support. I'll build my own version and report back here... Thanks! Paul Best, -berk On Mon, Oct 12, 2009 at 9:00 AM, Paul Melis paul.me...@sara.nl wrote: Hi, I'm trying to get paraview to handle rendering on a single GPU with dual-monitor outputs. These outputs are run using different X screens on the same X server. Using xinerama is not an option as this is a preliminary test setup for driving a TPD using nodes that each drive 2 displays and the mullions can't be handled correctly with xinerama. The goal is to run Paraview as described in https://visualization.hpc.mil/wiki/Paraview_Tiled-Display_Mode. The problem I have is to get multiple pvservers to run on the same host. I'm basically following the procedure outlined in Multiple GPUs Per Node on http://www.itk.org/Wiki/Setting_up_a_ParaView_Server. The -bynode mpirun line (supported by OpenMPI) works, but it leads to the different pvserver processes trying to listen on port 1: pa...@sara0143:/scratch/paulm/paraview-3.6.1-Linux-i686/bin$ mpirun -bynode -np 1 ./pvserver -display :0.0 : -np 1 ./pvserver -display :0.1 Listen on port: 1 Waiting for client... Listen on port: 1 ERROR: In /home/kitware/ParaView-3.6/ParaView3/Servers/Common/vtkProcessModuleConnectionManager.cxx, line 193 vtkProcessModuleConnectionManager (0x8216f60): Failed to set up server socket. As far as I understand it this port (1) is the combined server port that the client connects to, but the connections among different pvservers will use different (arbitrary) ports. So it seems two pvservers want to play the role of combined server entry point in my case. The mpirun line above is very similar to the one shown in the Setting_up_a_ParaView_Server wiki page: mpirun -bynode -np 8 ./pvserver -display :0.0 : -np 8 ./pvserver -display :0.1 Is there some information missing on that page that is needed to get this specific setup to work? I.e. something in an MPI hosts file? Thanks in advance, Paul ___ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
