vtkProgrammableFilter ain’t so bad

When I started preparing for this blog, my goal was to write about how awful vtkProgrammableFilter is to use in Python and how the new vtkPythonAlgorithm is superior. Funny enough, as I worked on a few examples, I discovered that vtkProgrammableFilter is not so bad if you know a few tricks. It does what it is supposed to fairly well. vtkPythonAlgorithm can do a lot more but more on that later.

In summary, vtkProgrammableFilter enables one to execute Python code within a pipeline. It is designed to perform relatively simple tasks without having to compile C++ classes. Actually, when combined with the numpy_interface module that I previously wrote about, it can do fairly complex and computationally intensive things too. Let’s start with a very simple example.

Lines 5 – 19 should be pretty obvious to a VTK initiate. They simply create a rendering scene. Line 21 – 32 create a simple pipeline consisting of a vtkSphereSource and a vtkProgrammableFilter. The Programmable Filter creates a new scalar array called Normals-x by extracting the first component of the Normals vector generated by the Sphere Source (lines 27–28). This function is assigned to the Programmable Filter on line 32. Pretty standard stuff. Still quite powerful if you consider that you have almost the entire VTK API plus the numpy_interface module.

What I really dislike about this is that on lines 24 and 25, we have to refer to the pf object that is in the global namespace. So, if we add something like this:

We will get the following error during execution:

Since the method passed to SetExecuteMethod cannot take any arguments, this seems like the only solution. It is kind of yucky. What is worse, if you want to re-use this method and tweak it by setting some parameters, you have to do it by adjusting global variables or write a new function for each new combination. Ugh.

We can get around the first problem if we can use a closure as follows.

This works fine because create_execute() returns a function object which has its argument bound within the function object’s scope (a closure). It still doesn’t address the configurability issue. I didn’t think that this problem could be solved. I was wrong. SetExecuteMethod accepts any callable object. So the following works very nicely.

An instance of a class that implements the __call__() method is callable. So we can call a MyAlgorithm as if it is a function:

Note that I used a weak reference to avoid a reference loop between the Programmable Filter and MyAlgorithm. We can now customize the programmable filter using the class interface.

Consider another example.

Here I added a Factor property to allow the configuration of the filter. In this example, pf will execute twice: the first when Update() is called (with Factor == 1), second during render (with Factor == 2). Note that Modified() on line 17 is necessary for this to work.

vtkProgrammableFilter works great for many use cases but has some limitations:

  • Its output type is always the same as its input type. So one cannot implement filters such as a contour filter (which accepts a vtkDataSet and outputs a vtkPolyData) using it. * It is not possible to properly manipulate pipeline execution by setting keys. We’ll discuss how this can be done using vtkPythonAlgorithm in a future blog. * The source counterpart of vtkProgrammableFilter, vtkProgrammableSource, is very difficult to use and is very limited. So if you want to create sources (readers for example), I strongly recommend using vtkPythonAlgorithm.

I’ll follow up with one or more blogs on vtkPythonAlgorithm.

One final note. The callable objects also work nicely as observers. See below.

will print

Questions or comments are always welcome!