Re: [Paraview] Inconsistent results with the stream trace filter
Yes, you're right. After increasing that, I get the result I expect. Thanks for this fix, it's very helpful. Regards, Joseph David Borġ http://www.jdborg.com On 2 November 2012 16:36, Yuanxin Liu leo@kitware.com wrote: I assume you are using the same parameters? In particular, did you set the Maximum Streamline Length to be large enough? The default is too small. Leo On Thu, Nov 1, 2012 at 12:04 PM, Joe Borġ m...@jdborg.com wrote: Hi Everyone, Seems the latest build (please check build number) has kept the problem. http://jdborg.com/images/paraview/pv_test.png Thanks, Joe Regards, Joseph David Borġ http://www.jdborg.com On 19 October 2012 17:05, Yuanxin Liu leo@kitware.com wrote: Hi, Joe, It looks like this was indeed a bug in 3.14.1 but the bug has been fixed in the current development branch. I am not entirely sure which commit explicitly did it. Leo On Fri, Oct 19, 2012 at 5:54 AM, Joe Borġ m...@jdborg.com wrote: Hi, I am using 3.14.1 64-bit on a single core (if I enable multi-core, it becomes very unstable). Adding tets to this small case works, but I've got a bigger duct with a more refined mesh and adding tets don't fix the problem (make it better though). See attached PVSM. Regards, Joseph David Borġ http://www.jdborg.com On 18 October 2012 19:00, Yuanxin Liu leo@kitware.com wrote: No, I did not use Tetrahedralize. Are you using the lastest development version? Are you running paraview as a single process? Do you mind saving a state file of your session and post it? thanks! Leo On Thu, Oct 18, 2012 at 4:31 AM, Joe Borġ m...@jdborg.com wrote: Hi Leo, You don't seem to have used the Tetrahedralise filter? How have you got this to work without that? Mine works fine after setting the fluid as input and source as the inlet, but I must first use the Tetrahedralise filter. Regards, Joseph David Borġ http://www.jdborg.com On 17 October 2012 18:14, Yuanxin Liu leo@kitware.com wrote: Hi Joe, I am not seeing exactly what you are seeing. In the attached image produced with the current master, I created a stream tracer with outlet block as the seeds and the fluid block as the input, and the streamlines seem right. But I think there is a bug in how the stream tracer handles multiblock data, because if I change the stream tracer input to the whole pipe data set, instead of just the fluid block, some stream lines go straight to the void like you described. Can you try setting up the pipeline as I did using ExtractBlock and compare with my image? Leo On Wed, Oct 17, 2012 at 10:51 AM, Magician f_magic...@mac.comwrote: Hi Joe, Tetrahedralize filter is applicable. All cells are splitted into Tetrahedral ones. Try it. Magician On 2012/10/17, at 23:40, Joe Borġ wrote: Thanks Magician, Thanks for testing. What are you using to convert to tet? Is it a ParaView feature? Leo, can the priority of the bug be raised please? Regards, Joseph David Borġ http://www.jdborg.com On 17 October 2012 14:20, Magician f_magic...@mac.com wrote: Hi Joseph, I tried your data and got a result as yours. Your data only includes Hex, Wedge, Tet and Pyramid, but streamlines are stopped earlier. Same as my polyhedral pipe sample, I applied Tetrahedralize filter to your pipe source, and I could get valid streamlines. Magician Pipe.tar.gz attached to the bug report below, in the form of an Ensight Case. First extract the archive and to open in Paraview, use All files (*) when browsing and select the .encas, then select EnSight Files. Regards, Joseph David Borġ http://www.jdborg.com On 12 October 2012 03:28, Yuanxin Liu leo.liu at kitware.com wrote: Hi, Is it possible for you to upload the data? By the way, if the cell type is polyhedron, then this is quite likely the same bug as this: http://paraview.org/Bug/view.php?id=13442 Leo On Thu, Oct 11, 2012 at 6:17 AM, Joe Borġ mail at jdborg.com wrote: Hi guys, I've got an odd issue with the stream trace and stream trace custom source filters in Paraview (3.14.1 64bit). No matter what settings I use, the traces die off very soon and some even carry on straight (even when there's no fluid). See the two screenshots I've got from Paraview. http://jdborg.com/images/paraview/pv_inlet.png http://jdborg.com/images/paraview/pv_outlet.png Not sure if this is a setting that's easy to miss or if it's more terminal. Thanks, Regards, Joseph David Borġ http://www.jdborg.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at:
[Paraview] Compile bug
Has anyone seen this bug, and have any idea how to get around it? Also, where is the link line created forlibvtkftgl-pv3.14.so? Thanks, Alan Linking CXX shared library ../../../lib/libvtkftgl-pv3.14.so cd /usr/local/viz/paraview/ParaView/3.98.0-Mesa/Linux-angren-RHEL4-32-i686/Build/VTK/ThirdParty/ftgl /usr/local/viz/paraview/support/Linux-angren-RHEL4-32-i686/install/cmake-2.8.8/bin/cmake -E cmake_link_script CMakeFiles/vtkftgl.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -w -O3 -Wl,--fatal-warnings -Wl,--no-undefined -lc -shared -Wl,-soname,libvtkftgl-pv3.14.so.1 -o ../../../lib/libvtkftgl-pv3.14.so.1 CMakeFiles/vtkftgl.dir/src/FTBitmapGlyph.cpp.o CMakeFiles/vtkftgl.dir/src/FTBitmapGlyphRenderOpenGL.cpp.o CMakeFiles/vtkftgl.dir/src/FTCharmap.cpp.o CMakeFiles/vtkftgl.dir/src/FTFace.cpp.o CMakeFiles/vtkftgl.dir/src/FTFont.cpp.o CMakeFiles/vtkftgl.dir/src/FTGLBitmapFont.cpp.o CMakeFiles/vtkftgl.dir/src/FTGLBitmapFontRenderOpenGL.cpp.o CMakeFiles/vtkftgl.dir/src/FTGLPixmapFont.cpp.o CMakeFiles/vtkftgl.dir/src/FTGLPixmapFontRenderOpenGL.cpp.o CMakeFiles/vtkftgl.dir/src/FTGlyph.cpp.o CMakeFiles/vtkftgl.dir/src/FTGlyphContainer.cpp.o CMakeFiles/vtkftgl.dir/src/FTLibrary.cpp.o CMakeFiles/vtkftgl.dir/src/FTPixmapGlyph.cpp.o CMakeFiles/vtkftgl.dir/src/FTPixmapGlyphRenderOpenGL.cpp.o CMakeFiles/vtkftgl.dir/src/FTSize.cpp.o /usr/local/viz/paraview/support/Linux-angren-RHEL4-32-i686/install/Mesa-7.10.3/lib/libOSMesa.a ../../../lib/libvtkfreetype-pv3.14.so.1 ../../../lib/libvtkzlib-pv3.14.so.1 -Wl,-rpath,/usr/local/viz/paraview/ParaView/3.98.0-Mesa/Linux-angren-RHEL4-32-i686/Build/lib: /usr/local/viz/paraview/support/Linux-angren-RHEL4-32-i686/install/Mesa-7.10.3/lib/libOSMesa.a(u_thread.o)(.text+0x1a): In function `u_tsd_init': ../../../src/mapi/mapi/u_thread.c:75: undefined reference to `pthread_key_create' /usr/local/viz/paraview/support/Linux-angren-RHEL4-32-i686/install/Mesa-7.10.3/lib/libOSMesa.a(u_thread.o)(.text+0x9e): In function `u_tsd_set': ../../../src/mapi/mapi/u_thread.c:99: undefined reference to `pthread_setspecific' /usr/local/viz/paraview/support/Linux-angren-RHEL4-32-i686/install/Mesa-7.10.3/lib/libOSMesa.a(u_thread.o)(.text+0x73): In function `u_tsd_get': ../../../src/mapi/mapi/u_thread.c:89: undefined reference to `pthread_getspecific' /usr/local/viz/paraview/support/Linux-angren-RHEL4-32-i686/install/Mesa-7.10.3/lib/libOSMesa.a(glapi_entrypoint.o)(.text+0x29): In function `init_glapi_relocs_once': /usr/local/viz/paraview/support/Linux-angren-RHEL4-32-i686/src/Mesa-7.10.3/src/mapi/glapi/glapi_entrypoint.c:342: undefined reference to `pthread_once' collect2: ld returned 1 exit status make[2]: *** [lib/libvtkftgl-pv3.14.so.1] Error 1 make[2]: Leaving directory `/usr/local/viz/paraview/ParaView/3.98.0-Mesa/Linux-angren-RHEL4-32-i686/Build' ___ 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] Using VR-Style input devices
Hi Johannes, However, some issues remain for me: 1) GUI-Improvements: - It would be nice if one could specify the TrackerTransform via the GUI - The ability to load tracker-configurations from a file would be handy - When connecting tracker-input to objects, it would be nice if only compatible properties were displayed. Sure, this is a good suggestion and we wanted to do this but ran out of time. - It would be nice if the grab tool would work globally, more like the mouse, and not have to be connected to a specific object. I am not so sure what you are saying here, because currently the grab style just works on the scene and not on a particular object. Current we don't perform intersection but you could extend the style to do so. 2) Display issues: - In a curved screen setup powered by 3 overlapping projectors, the perspective seems to be incorrect: This can be most easily observed when you move your head past the coordinate system origin. What I would expect to see is that the z-axis (pointing out of the screen) points somewhat to the right when my x-position is negative, and to the left when my x-position is positive. What I actually see is that the perspective of the axis-cross does not change. What could I have messed up in the configuration that would cause this? is it possible for you to share a movie? - When moving a Slice-plane using the tracker (SliceOrigin,SliceOrientation), the displayed slice plane is not updated. I can see that the plane was moved on the client window, but the actual slice is not affected. I have to move the plane a little with the mouse to trigger an update of the slice. Seems like a bug. We recently updated the slice style. Hopefully soon we will be pushing this branch to master. - Grabbing an object only affects the object in the client window, not the server view. When the Grab tool is connected to an object, I can move that object around, but I only see this in the client window. On the server side, things are totally unaffected by the changes. (I didn't test this one again with the new git master, so excuse me if it has been fixed since 3.14.1) I see. This particular style is not tested well and was intended for the testing purposes. 3) Loose ends I didn't find anything I can do with an analog input. Do I have to enable some special build option to enable those? It depends on the style. If a style needs an analog input, it will use it if configured correctly. Currently we don't have any interactor style that uses any analog input. if you do have such requirement, we could help you write one. Thanks for your valuable feedback. Best, Cheers, Johannes Am 24.10.2012, 17:01:37 schrieb Aashish Chaudhary: Hi Johannes, Very recently, we have improved the VR API and related tools and now the VR plugin comes with a GUI to configure connection managers and interactor styles. The way it works now is that you create a connection manager (lines 475 - 483), which will be generated by the GUI if used, and then for the styles, you would link it with the ID of the proxy and its specific property that you want to control. Now said that the GUI shows you the name of the proxy and not the ID for obvious reasons. Then depending upon the type of the proxy and property you specify a particular input from a HCI device. Currently we support analog, button, and tracker. The wiki here is bit old: http://www.paraview.org/Wiki/ParaView/Users_Guide/CAVE_Display We wrote a source article as well: http://www.kitware.com/source/home/post/66 This recent work is not in master yet (hopefully this Friday) but you can checkout this branch: vtk_vr_improvements_new_gui if you want to from paraview stage repository. The branch contains bunch of bug fixes, and API improvements. 475 VRConnectionManager 476 VRUIConnection name=vrui address=localhost port = 8555 477 Button id=0 name=1/ 478 Button id=1 name=2/ 479 Button id=2 name=3/ 480 Tracker id=0 name=head/ 481 Tracker id=1 name=wand/ 482 /VRUIConnection 483 /VRConnectionManager 484 VRInteractorStyles 485 Style class=vtkVRTrackStyle proxy=267 property=EyeTransformMatrix 486 Tracker name=vrui.head/ 487 /Style 488 Style class=vtkVRGrabWorldStyle proxy=267 property=ModelTransformMatrix 489 Tracker name=vrui.wand/ 490 Button name=vrui.1/ 491 /Style 492/VRInteractorStyles On Wed, Oct 24, 2012 at 9:40 AM, Johannes Zarl johannes.z...@jku.at wrote: Hi, I'm currently trying to configure ParaView for a CAVE-like environment. So far I was able to set up the pvservers correctly and even make headtracking over VRPN work. Myself, I'm more of a newbie concerning ParaView, so I'm having some trouble understanding the state-file and how to define a wand-device so that ParaView can use it.
