tacc / pvospray Goto Github PK

polydatamapper has local mallocs that need to be properly managed.

It seems when a cross section of a volume is extracted, the texture on the surface is totally wrong.

Under 'building', it says:

cd /Plugins

should this be "cd ParaView-v4.1.0/Plugins" ?

Also, what is "cd paraview_build_dir"? Do I have to first create this directory? If so, should I place that into the Plugins dir?

colormaps on volumes, and backgrounds do not color correctly. Issue with accumulation?

Aspect ratio of rendered image off on some cases, ie opening a split view.

phong will be different than gourand, but specular is overblown and not changing with updates

Greg P. Johnson wrote:

Can we disable LOD when OSPRay is used? Interaction is quite a bit slower with it on. I set LOD threshold to max to get around this.

outline representation does not work. Likely need to update both polydatamapper and xml representation.

Hello,

I am running paraview in client/server mode in a Powerwall (ORNL's EVEREST), it has 9 nodes, each node has two GPUs, each GPU is connected to a display. The system is using intel compiler 14.0.4 and openMPI 1.8.4 with multithread support. I am aware that you recommend MPICH, nevertheless I can run the ospTestMPIAsyncMessaging example with openMPI, so I am wondering if it is another issue.

The job for the pvserver allocates 18 tasks and assigns 2 tasks per node to "steer" each GPU.

I am able to get up and running paraview and pvserver and the pvOSPRay plugin is loaded in both sides.

...
Waiting for client...
Connection URL: cs://everest1:22222
Accepting connection(s): everest1:22222
Client connected.
...

However when I change the rendering view to OSPRay, I can see a kind of switching in the powerwall and then the client gets disconnected from pvserver. For simplicity I am just adding the errors I got in the head node

ERROR: In /ccs/home/benjha/Programs/rayTracing/Paraview/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 878
vtkSocketCommunicator (0x23ea400): Tag mismatch: got 22222, expecting 1.
[everest1:28234] *** Process received signal ***
[everest1:28234] Signal: Segmentation fault (11)
[everest1:28234] Signal code: Address not mapped (1)
[everest1:28234] Failing at address: 0x20
[everest1:28234] [ 0] /lib64/libpthread.so.0(+0xf710)[0x7fd366dae710]
[everest1:28234] [ 1] /ccs/home/benjha/Programs/rayTracing/Paraview/build/bin/../lib//libpvOSPRay.so(_ZN15vtkPVOSPRayViewD2Ev+0x68)[0x7fd33a683aa2]
[everest1:28234] [ 2] /ccs/home/benjha/Programs/rayTracing/Paraview/build/bin/../lib//libpvOSPRay.so(_ZN15vtkPVOSPRayViewD0Ev+0x18)[0x7fd33a683b18]
[everest1:28234] [ 3] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkCommonCore-pv4.3.so.1(_ZN13vtkObjectBase18UnRegisterInternalEPS_i+0xe6)[0x7fd367849526]
[everest1:28234] [ 4] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkCommonCore-pv4.3.so.1(_ZN9vtkObject18UnRegisterInternalEP13vtkObjectBasei+0x365)[0x7fd36784bb1f]
[everest1:28234] [ 5] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkCommonCore-pv4.3.so.1(ZN13vtkObjectBase10UnRegisterEPS+0x34)[0x7fd3678493e8]
[everest1:28234] [ 6] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkCommonCore-pv4.3.so.1(_ZN19vtkSmartPointerBaseD1Ev+0x45)[0x7fd367882863]
[everest1:28234] [ 7] [everest1:28231] *** Process received signal ***
[everest1:28231] Signal: Segmentation fault (11)
[everest1:28231] Signal code: Invalid permissions (2)
[everest1:28231] Failing at address: 0x36efa40
/ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkCommonCore-pv4.3.so.1(_ZN19vtkSmartPointerBaseaSEP13vtkObjectBase+0x66)[0x7fd3678828cc]
[everest1:28234] [ 8] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkPVServerImplementationCore-pv4.3.so.1(+0xcdc97)[0x7fd36d5cac97]
[everest1:28234] [ 9] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkPVServerImplementationCore-pv4.3.so.1(_ZN10vtkSIProxy16DeleteVTKObjectsEv+0x21)[0x7fd36d5c972f]
[everest1:28234] [10] [everest1:28231] [ 0] /lib64/libpthread.so.0(+0xf710)[0x7f39c0c21710]
[everest1:28231] [ 1] [0x36efa40]
[everest1:28231] *** End of error message ***
/ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkPVServerImplementationCore-pv4.3.so.1(_ZN10vtkSIProxyD2Ev+0x2d)[0x7fd36d5c768d]
[everest1:28234] [11] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkPVServerImplementationCore-pv4.3.so.1(_ZN10vtkSIProxyD0Ev+0x18)[0x7fd36d5c77b4]
[everest1:28234] [12] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkCommonCore-pv4.3.so.1(_ZN13vtkObjectBase18UnRegisterInternalEPS_i+0xe6)[0x7fd367849526]
[everest1:28234] [13] /ccs/home/benjha/Programs/rayTracing/Paraview/build/lib/libvtkCommonCore-pv4.3.so.1(_ZN9vtkObject18UnRegisterInternalEP13vtkObjectBasei+0x365)[0x7fd36784bb1f]
[everest1:28234] [14] [everest6:23019] *** Process received signal ***

I am wondering what could be the problem, any help will be appreciated.

Let me know if you need additional information.

Thanks,

Benjamin Hernandez
Advanced Data and Workflows Group
ORNL

Greg Abram wrote:

I created a little PVSM with a pvOSPRay window showing a wavelet source surface shaded colored by RTData. Reloading it crashes every time

does not work when saving screenshots with transparent backgrounds. Transparent backgrounds can be enabled in the advanced options under settings->general tab. Click the gear to get advanced settings. This setting appears to affect pvpython as well, images are not saved out at all with this enabled.

The "building" section on https://github.com/TACC/pvOSPRay talks about getting
a) a relatively old version of ospray, and
b) ispc-1.8.0.

Shouldn't we be using newer versions of both?

Stereo rendering is non functional in pvOSPRay

I tried to use OSPRay for rendering in ParaView but it seems I am getting a strange pattern inside it.

GL rendered.

OSPRay ray traced.

pvOSPRay should use the modularized vtkOSPRay - action item from meeting - Paul

As originally reported by R.Pichler on the ospray mailing list:
(moved from ospray mailing list to pvospray issues by iw)

Hi,

I built pvOSPRay for ParaView 4.3 and I can go through the two demos on
the page http://tacc.github.io/pvOSPRay/demos.html. When I tried to
apply it to my data I didn't work as soon as I used group datasets.
Hence, I was wondering if something is wrong with my build or if this
feature is not implemented. Based on the "Basic Walk-Trough" I can see
the same problem if I create two Wavelet sources and place them next to
each other. Then I apply group datasets and create a contour as in the
demo and only the contour in one of the wavelets is rendered. The same
procedure works fine using the standard Render View. Did anyone
experience something similar and find a workaround?

currently renders with black background and does not update the view appropriately

data itself seems to be updated, but not bounds of volume

If you do a wavelet and use an all-white colormap against a white background, you should get a all-white image - a polar bear in snow picture, because opacity * white + (1 - opacity) * white is white. You do in a RenderView, but not in an OSPRay window - places where the opacity is low are dark. Maybe the data value is multiplied by the opacity twice - once as part of the accumulation along the array and later against the background?

Greg Abram wrote:

With the standard RenderView, when you create a plane source it is immediately visible. This is true whether you are looking at the initial RV or you clobber if and create a new one. However, if you clobber the initial RV and create a pvOSPRay view, then create the plane source, it isn't visible until you reset the camera.

Greg Abram wrote:

Can't release to open source with all these dead comments and diagnostic messages

Greg Abram wrote:

GregP implemented the NEAREST interpolation scheme to make VTK's color-texture algorithm work. Changes were made to add the necessary flag to pvOSPRay, but equivalent changes will need to be made to make GLuRay track the interpolation mode and assign the OSPRay property accordingly. Otherwise, intercepting VTK OpenGL that implements Ken's algorithm will incur the color shifting problem.

github docs in readme.md not updated for 4.3

screenshot out does not work, or at least the image is misaligned

volumes do not render together with surfaces

tutorials need to be updated for 4.3.1

If you pop up a plane source using pvOSPRay with a solid white color, there is a visible regular grid of dots visible on the plane. It doesn't go away with over time unless you set the number of samples up.
Carson: This is likely an issue with shadows and the scene epsilon value being off.

LightKit does not work with pvOSPRay

Hi! I'm trying to build ParaView 4.4 with your pvOSPray plugin. Unfortunately, I get a build failure...

/Users/lyon/Development/paraview/paraview/ParaView/Plugins/pvOSPRay/ParaView/vtkQtProgressiveRenderer.cxx:11:10: fatal error:
      'vtkPVGenericRenderWindowInteractor.h' file not found
#include "vtkPVGenericRenderWindowInteractor.h"

... for every file in pvOSPray that tries to include vtkPVGenericRenderWindowInteractor.h . This header does not seem to exist in ParaView 4.4. E.g. find ParaView -name 'vtkPVGenericRenderWindowInteractor.h' -print yields nothing.

In fact the file MajorAPIChanges.md says that vtkPVGenericRenderWindowInteractor has been removed. From that file...

###Removed vtkPVGenericRenderWindowInteractor, vtkPVRenderViewProxy###

ParaView was subclassing vtkRenderWindowInteractor to create
`vtkPVGenericRenderWindowInteractor` to handle interaction. That piece of code
was potentially derived from an older implementation of
vtkRenderWindowInteractor and hence did what it did. Current implementation of
vtkRenderWindowInteractor lets the vtkInteractionStyle (and subclasses) do all
the heavy lifting. ParaView did that to some extent (since it has a
vtkPVInteractorStyle), but will was relying on
`vtkPVGenericRenderWindowInteractor`, `vtkPVRenderViewProxy` to propagate
interaction/still renders and other things. This has been refactored. ParaView
no longer uses a special vtkRenderWindowInteractor. All logic is handled by
observers on the standard vtkRenderWindowInteractor.

This change was done to make it easier to enable interactivity in `pvpython`.

See also: vtkSMRenderViewProxy::SetupInteractor(). Subclasses of pqView now pass
the interactor created by QVTKWidget to this method to initialize it.

See also: vtkSMViewProxyInteractorHelper.

Is there an easy change to make this work for ParaView 4.4? Thanks!! -Adam

With the OpenGL2 backend, open an OSPRayRendered3DView, create a Wavelet source and hit the Slice button - crashes without so much as hitting Apply.

I got pvOSPRay to build on the Mac with ParaView 4.4 (with the 4.4 branch of ovOSPRay and the devel branch of OSPRay). Things seem to work except that the OSPRay preferences do not appear in the preferences window. For example,

Any ideas? Thanks!

For now I capped the number of refinements, but there is a memory leak over time with continuous renderings. Likely due to creating new model each frame.