[vtk-developers] VTK-5 - Filter with multiple outputs

[Brad King]

Ovidiu Toader wrote:
>>Your filter will need to override the ProcessRequest method and look for 
>>a REQUEST_DATA_NOT_GENERATED. 
> 
> Thanks for this info! From your description it looks like this is what I am 
> looking for. I've already noticed this key but wasn't sure how to use it.
> After I found out that this particular request was the only one returning a 
> Null from request->GetRequest() I decided to move away from it because it 
> appears different from the other requests. 

The fact that GetRequest() returns NULL is a bug that I have fixed in 
the main tree.  I'll make sure the fix is merged to the 5.0 branch 
before the patch 0 release is tagged.

>> Override the ComputePipelineMTime
>>method and look at the request object for the output port that made the
>>request.  Return the MTime from the object corresponding to that output
>>port.
> 
> I tried this. My Algorithm overrides 
> ComputePipelineMTime(vtkInformation *request)
> 
> However, all the calls to this method have a Null request.

The ComputePipleineMTime pass used to be implemented just like any other 
request and was invoked through ProcessRequest with 
REQUEST_PIPELINE_MODIFIED_TIME.  The result was stored in output 
information with the PIPELINE_MODIFIED_TIME key.  While this 
implementation followed the generalized-request design of the new 
pipeline it was found to slow rendering framerates because the whole 
pipeline has to evaluate this request on every update even if nothing 
changes.

The new ComputePipelineMTime method was created as an optimization for 
this pass to speed things up.  A side effect of the optimization is that 
the usual information available from the request is missing.  For 
example, the FROM_OUTPUT_PORT would have to be set on the request each 
time it is sent back through a filter, which slows things down.  Someone 
else implemented this optimization and I'm not sure why the request 
argument was left on the method even though it is not used.  If you wish 
you can submit a bug report here:

http://www.vtk.org/Bug

that points out the missing information.  It may be possible to provide 
the information in the request without slowing things down for filters 
that don't use it but someone will have to investigate such an 
implementation.

Due to the missing FROM_OUTPUT_PORT information for the pipeline mtime 
pass my previously suggested approach may not work.  The pipeline design 
will still allow it to work if you create your own executive (perhaps as 
a subclass of vtkStreamingDemandDrivenPipeline) and setup your own mtime 
request with the proper information.  This will be very complicated though.

Instead I suggest that you split your filter into smaller filters each 
responsible for one of the outputs of your original filter.  Then you 
can create one housekeeping object that has instances of the other 
filters and forwards the parameter settings.

-Brad