MantisBT - VTK
View Issue Details

ID	Project	Category	View Status	Date Submitted	Last Update
0002391	VTK	(No Category)	public	2005-10-20 14:06	2016-08-12 09:54

Reporter	ovi
Assigned To	Brad King
Priority	normal	Severity	feature	Reproducibility	always
Status	closed	Resolution	moved
Platform		OS		OS Version
Product Version
Target Version		Fixed in Version
Project
Type

Summary	0002391: Filters with multiple outputs are not properly supported by the new pipeline
Description	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).
Steps To Reproduce
Additional Information
Tags	No tags attached.
Relationships
Attached Files

Issue History
Date Modified	Username	Field	Change
2011-06-16 13:11	Zack Galbreath	Category	=> (No Category)
2016-08-12 09:54	Kitware Robot	Note Added: 0036802
2016-08-12 09:54	Kitware Robot	Status	expired => closed
2016-08-12 09:54	Kitware Robot	Resolution	reopened => moved

Notes

From email discussion:

Ovidiu Toader wrote:
> I adapted the algorithm with multiple outputs to make use of the new
> ComputePipelineMTime. It seems to be working fine as long as I connect the
> outputs with the downstream filters using SetInputConnection.

Excellent. I'll get the changes so far merged to the VTK 5.0 branch.

> If I use a
> SetInput to connect one of the outputs with a downstream filter then I run
> again into the problem with multiple updates.

The problem is not with SetInput but with non-pipeline consumers like
vtkActor2D (of which vtkCubeAxesActor2D is a subclass). They update the input through the data object and not the port.

> I think that I undertand why
> this happens but I am not certain. Let's call "bbox" the output that is
> connected with a SetInput to the next filter. Calls to ComputePipelineMTime
> that arrive through the bbox output would receive a port = -1. As far as I
> understand, port == -1 means "give me the most recent timestamp on any of
> your outputs". As soon as that happens the pipeline will want to update all
> the outputs even though I may not need all of them. The best solution to this
> problem would be to not use SetInput anymore. Unfortunately, there are
> filters like vtkCubeAxesActor2D which do not accept a SetInput.

This is correct: port -1 means update all ports. The problem is caused because updating through the data object knows about the port number for only the REQUEST_UPDATE_EXTENT and REQUEST_DATA passes. Other passes like ComputePiplineMTime do not get the port number and just use -1. This can probably be fixed, and I'll look at it when I can.

> I am not sure
> if these are ever going to be upgraded. For now the only solution that I
> could find was to introduce another filter as a buffer between bbox and
> vtkCubeAxesActor2D. The new filter is connected using SetInputConnection to
> bbox. This feels more like a hack at the moment so if you have a suggestion
> for a better solution I would be happy to hear it.

There is a long-term desire to convert the rendering infrastructure to real pipeline members but no concrete schedule or funding yet.

-Brad

These changes were made to merge this fix into the VTK-5-0 branch:

cvs -q up -j1.29 -j1.30 Filtering/vtkAlgorithm.cxx
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.29 -j1.30 Filtering/vtkAlgorithm.cxx)" Filtering/vtkAlgorithm.cxx
  /cvsroot/VTK/VTK/Filtering/vtkAlgorithm.cxx,v <-- vtkAlgorithm.cxx
  new revision: 1.27.4.1; previous revision: 1.27

cvs -q up -j1.27 -j1.28 Filtering/vtkAlgorithm.h
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.27 -j1.28 Filtering/vtkAlgorithm.h)" Filtering/vtkAlgorithm.h
  /cvsroot/VTK/VTK/Filtering/vtkAlgorithm.h,v <-- vtkAlgorithm.h
  new revision: 1.25.2.1; previous revision: 1.25

cvs -q up -j1.29 -j1.30 Filtering/vtkCompositeDataPipeline.cxx
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.29 -j1.30 Filtering/vtkCompositeDataPipeline.cxx)" Filtering/vtkCompositeDataPipeline.cxx
  /cvsroot/VTK/VTK/Filtering/vtkCompositeDataPipeline.cxx,v <-- vtkCompositeDataPipeline.cxx
  new revision: 1.23.2.1; previous revision: 1.23

cvs -q up -j1.16 -j1.17 Filtering/vtkCompositeDataPipeline.h
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.16 -j1.17 Filtering/vtkCompositeDataPipeline.h)" Filtering/vtkCompositeDataPipeline.h
  /cvsroot/VTK/VTK/Filtering/vtkCompositeDataPipeline.h,v <-- vtkCompositeDataPipeline.h
  new revision: 1.12.2.1; previous revision: 1.12

cvs -q up -j1.40 -j1.41 Filtering/vtkDemandDrivenPipeline.cxx
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.40 -j1.41 Filtering/vtkDemandDrivenPipeline.cxx)" Filtering/vtkDemandDrivenPipeline.cxx
  /cvsroot/VTK/VTK/Filtering/vtkDemandDrivenPipeline.cxx,v <-- vtkDemandDrivenPipeline.cxx
  new revision: 1.37.4.2; previous revision: 1.37.4.1

cvs -q up -j1.19 -j1.20 Filtering/vtkDemandDrivenPipeline.h
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.19 -j1.20 Filtering/vtkDemandDrivenPipeline.h)" Filtering/vtkDemandDrivenPipeline.h
  /cvsroot/VTK/VTK/Filtering/vtkDemandDrivenPipeline.h,v <-- vtkDemandDrivenPipeline.h
  new revision: 1.18.4.1; previous revision: 1.18

cvs -q up -j1.27 -j1.28 Filtering/vtkExecutive.cxx
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.27 -j1.28 Filtering/vtkExecutive.cxx)" Filtering/vtkExecutive.cxx
  /cvsroot/VTK/VTK/Filtering/vtkExecutive.cxx,v <-- vtkExecutive.cxx
  new revision: 1.27.4.1; previous revision: 1.27

cvs -q up -j1.19 -j1.20 Filtering/vtkExecutive.h
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.19 -j1.20 Filtering/vtkExecutive.h)" Filtering/vtkExecutive.h
  /cvsroot/VTK/VTK/Filtering/vtkExecutive.h,v <-- vtkExecutive.h
  new revision: 1.19.4.1; previous revision: 1.19

cvs -q up -j1.30 -j1.31 Imaging/vtkImageOpenClose3D.cxx
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.30 -j1.31 Imaging/vtkImageOpenClose3D.cxx)" Imaging/vtkImageOpenClose3D.cxx
  /cvsroot/VTK/VTK/Imaging/vtkImageOpenClose3D.cxx,v <-- vtkImageOpenClose3D.cxx
  new revision: 1.30.4.1; previous revision: 1.30

cvs -q up -j1.33 -j1.34 Imaging/vtkImageOpenClose3D.h
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.33 -j1.34 Imaging/vtkImageOpenClose3D.h)" Imaging/vtkImageOpenClose3D.h
  /cvsroot/VTK/VTK/Imaging/vtkImageOpenClose3D.h,v <-- vtkImageOpenClose3D.h
  new revision: 1.33.4.1; previous revision: 1.33

...
then the fix for bug 0002402 was merged in ... then this:
...

cvs -q up -j1.42 -j1.43 Filtering/vtkDemandDrivenPipeline.cxx
cvs commit -m "ENH: Merge changes from main tree into VTK-5-0 branch. (cvs -q up -j1.42 -j1.43 Filtering/vtkDemandDrivenPipeline.cxx)" Filtering/vtkDemandDrivenPipeline.cxx
  /cvsroot/VTK/VTK/Filtering/vtkDemandDrivenPipeline.cxx,v <-- vtkDemandDrivenPipeline.cxx
  new revision: 1.37.4.4; previous revision: 1.37.4.3