Filters with multiple outputs are not properly supported by the new pipeline
This issue was created automatically from an original Mantis Issue. Further discussion may take place here.
Brief:
Lets say that $A is a vtkAlgorithm with 0 inputs and 3 outputs. $A has some methods which can affect differently the 3 outputs. Consequently, the outputs should be "scheduled for update" selectively based on state of $A. With the current VTK-4 pipeline implementation I am able to achieve this goal by making use of code like:
out->SetPipelineMTime(out->GetMTime()+1);
which works as intended because after this line of code is executed "out" will be out of date, thus being sent to $A's ExecuteData which will take care of it at the appropriate time. It appears that one cannot implement easily the functionality provided by the above line in VTK-5.
A more specific example:
A specific example of such a filter could be provided by a vtkAlgorithm that generates outputs related to a time varying electro-magnetic field. Output labeled "E-vec" would produce a time dependent vectorial data representing the electric field on a structured grid. Similarly, outputs "H-vec" or "S-vec" would produce other time dependent fields. Output named "E-int" would produce a time independent data representing the intensity of the E field on the same grid. "E-int" should not change as time changes but it should change when the algorithm is asked to resize the structured grid. The computation required for any of these fields can be quite complex, therefore it is highly desirable to generate and update only the outputs that are required by the downstream filters. In order to do this with a single vtkAlgorithm one needs the support of the current pipeline infrastructure, support which at the moment seems to be only partial.
The problem:
According to the discussion on the mailing list it appears that the problem starts at vtkAlgorithm::ComputePipelineMTime(vtkInformation *request)
This method is invoked prior to any ProcessRequest but does not receive the same information as ProcessRequest does. In fact request is always 0 in the current implementation. For the particular example described above it would be enough if request would contain the key FROM_OUTPUT_PORT.I am not certain that with this single key one could provide the maximum flexibility but I am certain that a Null request makes it impossible for the vtkAlgorithm to handle multiple independent outputs (like E-vec and E-int in the example above).