[vtkusers] How to get the input to a filter as algorithm output?

[David Gobbi]

On Tue, Dec 15, 2009 at 9:07 AM, David Doria <daviddoria+vtk at gmail.com> wrote:
> On Tue, Dec 15, 2009 at 9:41 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Where to start... there are a couple important items here.
>>
>> First, there's nothing wrong with directly accessing data objects when
>> you are writing a VTK filter.  Obviously the filter must access the
>> data.  That's completely different from accessing the data objects
>> outside of the filters, and whenever I said "don't mess with the data
>> objects", I really meant "if you want to mess with the data, then
>> write a filter".
>>
>> Second item: In VTK it isn't safe to write a VTK filter that executes
>> other VTK filters inside of it.  Which is really unfortunate, because
>> it sure is a useful thing to be able to do.  But if you look through
>> all the filters in VTK (i.e. vtkAlgorithm derived objects), you will
>> not find a single one that does this.
>>
>> Each vtkAlgorithm has an executive that deals with the vtkInformation
>> and sends Requests to the vtkAlgorithm.  If, internally, you grab the
>> algorithm's input and feed it into your little "internal pipeline",
>> then that internal pipeline will propagate its own requests to the
>> input's producer.  As a result a RequestData in the main (external)
>> pipeline can cause the internal pipeline to update, which causes all
>> sorts of requests to be sent up both the internal and external
>> pipeline before the RequestData completes.  This is a violation of the
>> usual, careful way that the pipeline is supposed to step its way
>> through the various requests.  It may result in undefined behavior of
>> the pipeline.
>>
>> It would be nice if someone devised a recipe for how to safely use a
>> mini-pipeline inside a VTK filter, by using deep copies of the data
>> objects or whatnot, but so far I haven't seen one.  About the closest
>> thing that I've done is use ITK from inside a VTK filter.
>>
>>   David
>
> David G.,
>
> Congratulations! You have just been appointed the resident pipeline
> expert by Jerome and me.

Uh oh.  I never bargained for that.  Maybe this honor should instead
go to one of the fine folks at Kitware?

> Your first function in this new role is to
> explain the difference between ports and connections (i.e. when you
> should use both? what is the difference? how to setup both, etc).
> Unfortunately this new position does not come with a pay increase ! :(

Dave DeMarle already answered.  The "port" and "connection" are really
just numbers.  An algorithm can have multiple output ports 0,1,2,3
etc. and multiple input ports 0,1,2,3 etc.  As well, an input port can
potentially have multiple connections, which is why you call
"SetInputConnection()" or "AddInputConnection" to connect to an input
port.

The "Port" and "Connection" are not VTK objects, they're just
descriptive terms.  You can kind of think of a vtkAlgorithmOutput as a
"Port" since it is returned by the GetOutputPort() method, but that
isn't quite correct.  A vtkAlgorithmObject is just a container that
holds a port number and a pointer to a producer.

> I have started two shell examples:
> http://www.cmake.org/Wiki/VTK/Examples/Developers/Multiple_Input_Ports
> http://www.cmake.org/Wiki/VTK/Examples/Developers/Multiple_Connections
>
> Could you fill in a few lines to demonstrate the differences?

Hmm... maybe.  I'll take a look later today.  As I said, you're
mistaken about me being the resident expert.

> SetInputConnection(vtkPolyData*) does not work because it is expecting
> an AlgorithmOutput. This is the same thing you told me not to do with
> vtkImageData. Do we need to make a "vtkGenerateEmptyPolyData" filter
> or something for this type of thing to fit into the pipeline model?

You must have misunderstood me somewhere along the line.  I said that
the "Port" and "Connection" methods are preferred.  But if you end up
with a vtkDataObject in your hands, then you have to use the old-style
SetInput() method.  That's a given, since there's no other choice.

   David