Hi everyone,
I created a new Plugin for ParaView that just provides some additional vtk filters. To this end I used the paraview-src/Examples/Plugins/ElevationFilter template.
Now comes the tricky part. One filter is supposed to use a vtkm filter under the hood (specifically <vtkm/rendering/ScalarRenderer.h>). I build PV with vtkm and I can build my plugin with this header. However, at runtime PV crashes when it wants to lookup the ScalarRenderer symbol (shared lib issues…). Strangely enough, I’m able to use <vtkm/filter/clean_grid/CleanGrid.h> within my filter without problems. So I guess something goes wrong with the vtkm::rendering export or I need to link to something in my vtk.module or paraview.plugin files. The source code of my plugin can be found here: pycinema-paraview-plugin.
Can anyone give me some pointers here (especially @Kenneth_Moreland)? I’m out of ideas how to address this.
Let me provide some context. In short, TTK follows a different approach to exporting Cinema databases than Paraview. Roughly speaking, in PV the Cinema export is kind of build around the VTK processing pipeline, but it is not part of it. In TTK the Cinema export is done via actual VTK filters. For example, the ttkImaging filter consumes a set of camera locations and a vtkDataSet that needs to be rendered. The filter than generates for each location a vtkImageData object via raycasting (currently done via Embree). Making the Cinema export part of the pipeline has several advantages. For instance, one can write a filter that consumes contours to produce a set of good camera positions; those can then be fed into the ttkImaging filter. Another advantage is that this kind of export does not require paraview. I think it is super neat and clean that the rendering and export is part of the processing pipeline.
However, there are some technical issues with Embree + VTK. For instace, Embree only supports 32-bit connectivity lists, but VTK/ParaView by default uses 64-bits, which means we currently have to do a data copy. Btw., if anyone reads this who did the Ospray integration in ParaView: you must have ran into the same issue, do you also just do a data copy?
So to get around the data copy and the additional dependency, I want to swap out the Embree backend with vtkm. In another project I already exported a Cinema database with the vtkm ScalarRenderer, but that was a standalone project that only imported vtkm. Now I want to make this work with the ParaView Plugin architecture without having to install additional dependencies.
I actually did set the VTKm_MODULE_ENABLE_vtkm_rendering variable to YES while building PV (before I did that I was not even able to find the ScalarRenderer header). However, the shared libs are still missing.
This is probably more of a question for @sujin, who has been working on the VTK-m to VTK/ParaView interface. It seems reasonable that you could adjust the CMake to allow a (hidden/advanced) option to turn on VTK-m rendering, which should solve the problem as long as you are compiling your own version of ParaView.
I already have concerns about the number of permutations the VTK build system can output. If there’s some rendering bit that VTK should expose through VTK-m, that might be the better way of doing it. Of course, we could also support using an external VTK-m and then VTK doesn’t need to juggle umpteen VTK-m permutations in its own CMake code (even if “hidden/advanced”; it’s either supported or not) and instead can just say “no, that VTK-m doesn’t support what you’ve requested I build” if something isn’t suitable.
If we don’t want to support all the VTK-m flags in VTK, then external vtk-m is the way to go. Though, It will take some effort to implement support for external VTK-m.