[vtkusers] How to disable a VTK filter that is connected to a VTK pipeline

[David Doria]

On Tue, Apr 20, 2010 at 9:22 AM, Jeff Baumes <jeff.baumes at kitware.com> wrote:
>> nextFilter->SetInput(reader->GetOutput());
>> //nextFilter->SetInput(lastFilter->GetOutput());
>
> You should really use this new method instead of SetInput/GetOutput:
>
> nextFilter->SetInputConnection(reader->GetOutputPort());
>
>> When I want to test what happens when I skip a filter. It would make a lot
>> more sense to call lastFilter->Disable(). In cases where the output type is
>> the same as the input type, we could make Disable() just pass the input
>> through to the output. In cases where they DONT match, I don't think it
>> makes sense to disable the filter.
>> Any comments from the devels?
>
> Conceptually this sounds like a reasonable idea. But Disable() would
> only make sense on filters with one input and one output that do not
> change the type of the input. It would be confusing what would happen
> with multiple inputs/outputs, or if the filter converts from one type
> to another. So I don't think it makes sense to have a Disable() at the
> vtkAlgorithm level. And there is no superclass for "algorithms with
> one input, one output, and the type doesn't change", so Disable()
> would probably have to be implemented multiple places.
>
> If someone still wants to look into this, vtkPassThrough is the filter
> logic that implements the "disabled" state you want.
>
> Jeff
>

It would definitely have to be implemented in multiple places, which
is unfortunate, but not tragic.

It could be implemented in the filters that it does make sense in very
easily, like this:


public:
  vtkSetMacro(Disabled, bool);

private: bool Disabled;

vtkExampleClass::function()
{
  if(this->Disabled) {shallow copy input to output and return;}

 ... do normal stuff ...
}

Thanks,

David