View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002391VTK(No Category)public2005-10-20 14:062016-08-12 09:54
Reporterovi 
Assigned ToBrad King 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0002391: Filters with multiple outputs are not properly supported by the new pipeline
DescriptionBrief:

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).
TagsNo tags attached.
Project
Type
Attached Files

 Relationships

  Notes
(0003170)
Brad King (developer)
2005-10-20 14:48

 I'm assigning this bug to myself because I asked the reporter to report it.
(0003171)
Brad King (developer)
2005-10-20 14:49

 I'm adding Ken as a CC on this bug because he made the ComputePipelineMTime optimization that introduced this bug.
(0003181)
Brad King (developer)
2005-10-24 14:04

 I've generalized the ComputePipelineMTime method to be a full ProcessRequest-like method used only for the pipeline modified time request. Method arguments are used for the common information in this request. This preserves the optimization while allowing full functionality.

The following changes were made to address the problem:

/cvsroot/VTK/VTK/Filtering/vtkAlgorithm.cxx,v <-- vtkAlgorithm.cxx
new revision: 1.30; previous revision: 1.29
/cvsroot/VTK/VTK/Filtering/vtkAlgorithm.h,v <-- vtkAlgorithm.h
new revision: 1.28; previous revision: 1.27
/cvsroot/VTK/VTK/Filtering/vtkCompositeDataPipeline.cxx,v <-- vtkCompositeDataPipeline.cxx
new revision: 1.30; previous revision: 1.29
/cvsroot/VTK/VTK/Filtering/vtkCompositeDataPipeline.h,v <-- vtkCompositeDataPipeline.h
new revision: 1.17; previous revision: 1.16
/cvsroot/VTK/VTK/Filtering/vtkDemandDrivenPipeline.cxx,v <-- vtkDemandDrivenPipeline.cxx
new revision: 1.41; previous revision: 1.40
/cvsroot/VTK/VTK/Filtering/vtkDemandDrivenPipeline.h,v <-- vtkDemandDrivenPipeline.h
new revision: 1.20; previous revision: 1.19
/cvsroot/VTK/VTK/Filtering/vtkExecutive.cxx,v <-- vtkExecutive.cxx
new revision: 1.28; previous revision: 1.27
/cvsroot/VTK/VTK/Filtering/vtkExecutive.h,v <-- vtkExecutive.h
new revision: 1.20; previous revision: 1.19
/cvsroot/VTK/VTK/Imaging/vtkImageOpenClose3D.cxx,v <-- vtkImageOpenClose3D.cxx
new revision: 1.31; previous revision: 1.30
/cvsroot/VTK/VTK/Imaging/vtkImageOpenClose3D.h,v <-- vtkImageOpenClose3D.h
new revision: 1.34; previous revision: 1.33

Algorithms that implement ComputePipelineMTime now have access to the output port that made the request (-1 for all ports).

I'm marking this bug as Resolved/Fixed. Please update and try it. If it works change the bug status to Verified and then I will close it. Otherwise report the new problem. Thanks.
(0003184)
Brad King (developer)
2005-10-24 16:30

 While fixing this bug I noticed a problem with the signature of the executive's ProcessRequest and ComputePipelineMTime methods. This problem is documented in bug#2402. The fix may change the signature of these methods again and will affect people interested in this bug.
(0003188)
Brad King (developer)
2005-10-24 18:35

 The following changes are also needed to avoid compiler warnings:

/cvsroot/VTK/VTK/Filtering/vtkDemandDrivenPipeline.cxx,v <-- vtkDemandDrivenPipeline.cxx
new revision: 1.43; previous revision: 1.42
/cvsroot/VTK/VTK/Filtering/vtkCompositeDataPipeline.cxx,v <-- vtkCompositeDataPipeline.cxx
(0003251)
Brad King (developer)
2005-11-16 12:10

 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
(0003252)
Brad King (developer)
2005-11-16 12:12

 I'm assigning this to Dave cole to have the changes merged to the VTK 5.0 branch. Please reassign it to me when you are done.
(0003256)
David Cole (developer)
2005-11-17 14:40

 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
(0003471)
Brad King (developer)
2005-12-21 09:43

 I'm re-opening this bug because one issue mentioned in the discussion has not been fixed. Currently only a subset of the pipeline passes send the port number through which a request is made if initiated from a vtkDataObject.
(0036802)
Kitware Robot (administrator)
2016-08-12 09:54

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current VTK Issues page linked in the banner at the top of this page.

 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

Copyright © 2000 - 2018 MantisBT Team