Reviving old custom rendering plugin code from pv 4.4

Development
1

Hi all, I’ve not been active with paraview for almost 10 years and I have some custom rendering code that uses vtkPiston with cuda/thrust and a front end that creates a custom representation and painters to draw the scene. The last time the code was compiled and run was around 2016 and I have a plugin branch that is labeled pv-4.4 (with a 2016 date stamp) so I’m guessing that is the last version of paraview it worked with.

Question : Have the representation/painter classes changed significantly (and the way you bind them via the client server interface etc)

The classes I’d like to get running again formed an astrophysics viz renderer using a customized splotch renderer and the (paraview parts of the) files have names like …

pqSplotchDisplayPanelDecorator.cxx
pqSplotchDisplayPanelDecorator.h
pqSplotchDisplayPanelDecorator.ui
pqSplotchPropertyWidgetDecorator.cxx
pqSplotchPropertyWidgetDecorator.h
vtkSplotchDefaultPainter.cxx
vtkSplotchDefaultPainter.h
vtkSplotchPainter.cxx
vtkSplotchPainter.h
vtkSplotchRepresentation.cxx
vtkSplotchRepresentation.h
vtkSplotchRepresentation.xml
vtkCUDASplotchPainter.cxx
vtkCUDASplotchPainter.h
… plus a ton of other stuff related to vtkpiston/thrust interfaces to paraview

which gives a clue as to how they fit together (roughly). I have not looked at the latest paraview code (especially plugin related api) to see how much it has changed so I’m wondering

Questions: 1) Is there any chance at all, that this stuff might still mostly compile and I can get it running in a day or three - or has the pv backend changed so much that all the class hierarchies are broken and everything will need rewriting from scratch.

  1. is there a decent astrophysics renderer built into vtkm or equivalent that might be a better choice than reviving this code.

  2. if 2) is a no, Does vtkm have any custom render modules that I can use as examples to redo this in a more modern way so that I can port some of the rendering directly to vtkm, then bolt on a prepackaged custom renderwindow from vtkm etc etc …

Thanks for any updates on the code status. I’m very rusty with paraview

JB

2

@Sankhesh_Jhaveri?

Yes, the CMake API has been changed since 4.4. I’d encourage looking at a similar plugin in ParaView’s Plugins/ directory for how it should look (perhaps Plugins/BivariateRepresentations)?

The CMake will certainly need to change, but it should be simpler if anything:

  • move classes that need wrapped to a module
  • do the VTK module CMake for it (BivariateRepresentations does this if you want to crib)
  • tell the plugin that there’s an associated module

then in the top-level (roughly):

find_package(ParaView REQUIRED)
paraview_plugin_scan(…)
paraview_plugin_build(…)

see SMTK’s ParaView plugin build bits for an example of doing this outside of ParaView. Yes, there are a lot of parameters, but there’s a lot going on too. They are documented.

3

I don’t think everything needs to be rewritten from scratch but the rendering backend changed in ParaView 5.0 and with it some of the properties. The painter classes at this point might be obsolete but you should be able to use some of the new features like the vtkPointGaussianMapper with its customized shaders for each point.