[vtk-developers] Bug in vtkCompositeDataPipeline?

[Jeff Lee]

So is this right, you are setting the input of the 
vtkStructuredGridOutlineFilter  with a vtkMultiBlockDataSet?  If not, 
can you post a prototype pipeline?  vtkStructuredGridOutlineFilter 
doesn't accept any input other than vtkStructuredGrid.  
FillInputPortInformation could take a dataset and do the appropriate 
thing for a multiblock dataset consisting of structured grids, or just 
process the structured grids.  But this should probably be another 
filter along the lines of vtkMultiGroupDataGeometryFilter... 
-Jeff

Bill McGrory 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
>>
>>     
>
>
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>