[vtk-developers] Bug in vtkCompositeDataPipeline?

[Berk Geveci]

Uh-oh. This will never work. Adding a dataset to a composite dataset does
not guarantee pipeline connectivity (as you found out). Neither should it.
Actually, it is safest if you do not add a dataset that is the output of a
source to a composite dataset. What you need is a group filter. One that has
multiple outputs and produce one composite data output. By the way, things
may also break because you are using a subclass of vtkSource. vtkSource is
now legacy and is there for backwards compatibility. However, since the
composite data pipeline does not have to be backwards compatible, it is not
required to work with the compatibility layer. I recommend subclassing from
vtkAlgorithm (or one of it's subclasses).
Also, please note that the composite data pipeline stuff is still maturing
and it is very likely that there will be implementation and API changes.

-Berk

On 5/26/06, Bill McGrory <mcgrory at aerosft.com> wrote:
>
> Yes, that is correct.
> I have two datasets constructed from two custom sources.
> I put these two datasets into a multiblock dataset.
>
> multiblock dataset is then fed to a structuredgridoutline filter.
>
> this is fed to a vtkMultiGroupDataGeometry filter and mapped.
>
> Before adding the patches listed below, the vtkStructuredGridSource
> never receives a ExecuteData call.
>
> If I fill the two datasets by hand, before adding them to the multiblock
> dataset then everything works as expected.
>
> Likewise, if I simply feed the vtkStructuredGridSource->GetOutput()
> directly to the Outline filter (bypass the multiblock dataset) then the
> source correctly gets the ExecuteData call as well.
>
> Regards
> Bill
>
> On Thu, 2006-05-25 at 16:55 -0400, Berk Geveci wrote:
> > I am not sure I understand. You have a few datasets, you add these to
> > a multiblock dataset, you process this multiblock dataset with a
> > filter. Is that right?
> >
> > On 5/25/06, Bill McGrory <mcgrory at aerosft.com> wrote:
> >         I've been trying to get a
> >         vtkMultiBlockDataSet to work properly with vtkStructuredGrid's
> >         which are
> >         output from a vtkStructuredGridSource
> >
> >         >From what I can tell, it appears that the
> >         the  vtkCompositeDataPipeline
> >         is unaware of child vtkDataObject->Source, so none of the data
> >         ever gets
> >         loaded.
> >
> >         I have constructed a work-around which appears (superficially
> >         at least)
> >         to work for my particular case, which is basically, if a
> >         Source exists
> >         for the original vtkDataObject in the *ForBlock() routines,
> >         call the
> >         relevant Update's before performing the ShallowCopy
> >
> >         patch is as follows
> >
> >         Index: vtkCompositeDataPipeline.cxx
> >
> ===================================================================
> >         RCS
> >         file: /cvsroot/VTK/VTK/Filtering/vtkCompositeDataPipeline.cxx,v
> >         retrieving revision 1.34
> >         diff -u -r1.34 vtkCompositeDataPipeline.cxx
> >         --- vtkCompositeDataPipeline.cxx        7 Dec 2005 16:21:29
> >         -0000       1.34
> >         +++ vtkCompositeDataPipeline.cxx        25 May 2006 19:48:48
> >         -0000
> >         @@ -35,6 +35,8 @@
> >         #include "vtkStructuredGrid.h"
> >         #include "vtkUniformGrid.h"
> >
> >         +#include "vtkSource.h"
> >         +
> >         vtkCxxRevisionMacro(vtkCompositeDataPipeline, "$Revision: 1.34
> >         $");
> >         vtkStandardNewMacro(vtkCompositeDataPipeline);
> >
> >         @@ -46,6 +48,28 @@
> >
> >
> vtkInformationKeyMacro(vtkCompositeDataPipeline,INPUT_REQUIRED_COMPOSITE_DATA_TYPE,
> String);
> >         vtkInformationKeyMacro(vtkCompositeDataPipeline,UPDATE_BLOCKS,
> >         ObjectBase);
> >
> >         +class vtkCompositeDataPipelineToDataObjectFriendship
> >         +{
> >         +public:
> >         +  static void UpdateDataObject(vtkDataObject* obj)
> >         +    {
> >         +               if(obj->Source)
> >         +               {
> >         +                       obj->Source->Update();
> >         +               }
> >         +
> >         +    }
> >         +
> >         +  static void UpdateInformation(vtkDataObject* obj)
> >         +    {
> >         +               if(obj->Source)
> >         +               {
> >         +                       obj->Source->UpdateInformation();
> >         +               }
> >         +
> >         +    }
> >         +};
> >         +
> >
> //----------------------------------------------------------------------------
> >         vtkCompositeDataPipeline::vtkCompositeDataPipeline()
> >         {
> >         @@ -490,6 +514,7 @@
> >                  info->Get(vtkDataObject::DATA_OBJECT());
> >                if (dobj && dobjCopy)
> >                  {
> >         +
> >
> vtkCompositeDataPipelineToDataObjectFriendship::UpdateInformation(dobj);
> >                  dobjCopy->ShallowCopy(dobj);
> >                  dobjCopy->CopyInformation(dobj);
> >                  }
> >         @@ -1089,6 +1114,7 @@
> >
> >                  if (dobj && dobjCopy)
> >                    {
> >         +
> >
> vtkCompositeDataPipelineToDataObjectFriendship::UpdateDataObject(dobj);
> >                    dobjCopy->ShallowCopy(dobj);
> >                    }
> >                  }
> >
> >
> >         Is this really a bug, and is this an appropriate fix?
> >         Or am I doing something wrong up the pipeline, such that I
> >         shouldn't
> >         need to do this?
> >
> >         Regards
> >         Bill
> >         _______________________________________________
> >         vtk-developers mailing list
> >         vtk-developers at vtk.org
> >         http://www.vtk.org/mailman/listinfo/vtk-developers
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20060526/2076cc26/attachment.html>