[Paraview-developers] Filter with multiple time-aware outputs

[Utkarsh Ayachit]

Ellon,

One thing to note is that ParaView/VTK pipelines don't support
pipeline loops. Based on what you explained, the "loop" is within a
data filter, namely "ICP Core". So rather than thinking of it as a
loop, think of it as a data producer that keeps on generating new
data/timesteps. Okay, so let's say we'll remodel ICPCore so that it
has a method which someone can call to make the filter "discover" new
timesteps, e.g. ICPCore::DiscoverTimesteps(). In this method, if new
timesteps are discovered, make sure to call this->Modified() on the
filter.

Now the next step would be to periodically call this method on the
filter to make it register new timesteps and tell that to ParaView UI.
For starters, just add a <Property name="DiscoverTimesteps"
command="DiscoverTimesteps" /> property to the XML for ICPCore. That
will show up as a button (using pqCommandPropertyWidget) in the
Properties panel. Check pqCommandPropertyWidget::buttonClicked(),
where it calls UpdatePipelineInformation() on the filter proxy, which
in will call DiscoverTimesteps() and the RequestInformation() on the
filter where it can announce the new timesteps (along with the old
ones).

Once this is working, you can automate this by using a timer-based
loop to periodically trigger the DiscoverTimeSteps property if you
want.

Hope that helps,
Utkarsh

On Sat, May 28, 2016 at 6:43 AM, Ellon Paiva <ellonpaiva at gmail.com> wrote:
>     Utkarsh,
>
> On 05/27/2016 02:42 PM, Utkarsh Ayachit wrote:
>>>
>>> Is it possible to trigger a file reader from a filter input? If it's
>>> possible I think I can achieve this using two filters in sequence in the
>>> pipeline: the first dump data on files, and the second would read the
>>> data
>>> from the disk when it receives a new data on its input port. This way the
>>> second filter would know already the number of time steps in its
>>> RequestInformation() to configure the output ports before reading the
>>> files.
>>
>> I am not sure I follow, but what I followed doesn't seem like it would
>> work. The second filter still only receive new data on its input in
>> RequestData() so not sure how it will already know the timesteps.
>
>
> Well, if I know the path to the files I'm writing in the first filter (for
> example: /tmp/myfiles_1.vtk, /tmp/myfiles_2.vtk, etc) I could just check how
> many of these files exist in the disk, and this number would be the number
> of time steps. The value of the timesteps is just the index of the file (1,
> 2, etc).
>
>> Do you want to try explaining what are you trying to do succinctly,
>> maybe someone can suggest an alternative approach.
>
>
> OK, let me explain. I'm using a library that performs ICP (libpointmatcher)
> on point clouds. The library itself is very modular on it's components (data
> filters, error minimizers, matchers, outlier rejectors, etc), it's
> structured in a pipeline fashion, like in ParaView. It has already an option
> to inspect the ICP process by dumping the point clouds (i.e. the reference
> cloud and the one being matched) and the point associations between these
> clouds in .vtk files (three files for every iteration of the ICP loop).
> These files can be loaded on ParaView through a standard reader and it's
> possible to inspect the ICP process through animation.
>
> What I want to implement is a way to reconfigure the parameters of the
> libpointmatcher's ICP pipeline through ParaView, in a way that if a
> parameter is changed in any libpointmatcher module in paraview (through
> filter properties), one can just press "Apply" to trigger the ICP run and
> the result would be exhibited in ParaView. I believe this would improve the
> workflow of configuring ICP solutions using this library.
>
> The data filters classes are already wrapped, and I want to wrap the "ICP
> core". As an iteractive process, it has a loop, and currently I don't know
> how to implement loops in paraview's pipeline (I know there's something to
> do with a vtkExecutive) and also the pipeline would be somehow complex for
> the user to build. So I decided to create a single filter that wraps all the
> loop part of the ICP pipeline.
>
> But then you told me I cannot configure dynamically the number of outputs of
> a filter from inside it's RequestData(), and I don't know how many
> iteractions of ICP I'll need before converging (if converging). One
> information I have is the maximum number of iteractions I may have, but the
> algorithm may finish before it.
>
> I'm attaching a image of the pipeline I was implementing here. This may help
> you to understand.
>
> Sorry for the long email.
>
> Regards,
>
> Ellon
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at:
> http://markmail.org/search/?q=Paraview-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview-developers
>