Filter supposed to react to animation steps

Busy with writing custom plugins in C++, and currently dealing more with animations, and there I am having a little problem where probably somebody knows very quickly how to deal with it!

Starting with a numbered CSV table series: Reading these with the “CSV Reader” results in an “animation” that can be “run”: the numbers are changing in the “SpreadSheet View” from step to step, as expected.

Now I have one simple filter, let’s call it A, that takes a table as input and generates one as output. I did nothing special for enabling animations, but it works: “Running” the animation will also update the output table of filter A.

Then I have a much more complex filter, call it B. That one takes a geometric input in the first input port and a table in the second. There I attach my “table animation” - expecting that also in this case the output of filter B will change according to the animation steps.

However, this is not happening!

And what I can also see through proper “trace” output: Going from time step to time step, the RequestData() function of filter B is not called, just as if the pipeline system does not “tell” this filter that something in the upstream has changed.

My guess: Maybe there is some function call required to set the input pipes to “modified” that is automatically called for simple filters with only one input pipe, but has to be called explicitly if ONLY the second input pipe is changing?

The easiest case would of course be an example: So far this is the way how I am dealing with such problems normally. But so far I did not come across such a filter that I could investigate for that purpose.

Just did another trial: I can make the setup with filter B work if I first make as many copies of the input geometry file (input pipe 0) as there are time steps in the input pipe 1 (CSV files): Now I can “run” the animation, and each timestep is calculated correctly!

Conclusion: Looks like that animation is working only if input pipe 0 is already a sequence of input files, but not if only input pipe 1 is a sequence.

@nicolas.vuaille this kinda rings a bell. Wdyt ?

Well, TimeSteps are forwarded through the RequestInformation, thanks to the TIME_RANGE() and TIME_STEPS() information keys.

I can only suppose that the default impl only look at the first input to generate the list… I do not know if we want to modify this but in your case reimplementing RequestInformation should do the trick

See this example: https://gitlab.kitware.com/vtk/vtk/-/blob/ac4764a272da7cbf60f498522d01b26c0ee0dcfb/Filters/Core/vtkProbeFilter.cxx#L916

In VTK and ParaView, when time is the only thing changing, only pipelines that are impacted by time would be re-executed. In other words, unless the source or filter produced time, there’s no exepectation that it would produce data any differently if time changed and hence those pipelines are not executed.

So for your case, you’ll need to make Filter B a time-aware filter. Looking at an existing filter that does that, see vtkTimeToTextConvertor (aka Annotate Time Filter) You can apply this filter to Sphere and it would still re-execute when time changes.

Thanks to all for this very helpful hint: Adding that RequestInformation function to my “filter B” and doing there these info copy calls made it work!

I realized that I had to do one more thing: In my question I simplified the description of “filter B” to the minimum that I considered crucial. In reality it is a rather complex thing, doing some linear optimization calculations, with the input of pipe 1 being a definition for the constraints: Running the “animation” has now the effect of doing a series of optimizations in a sequence nicely.

However, output is also not only one pipe, but actually 5 different pipes (doing jobs that could have been “outsourced” to a series of other filters of course). The point is: I have to do this info copy job for all available output ports, because otherwise they are not automatically updated either.

Bottom line: I could implement a very useful function with very little code, but a lot of learning for myself - so again thanks to those who contributed!