[vtkusers] vtkAppendPolydata - wrong extents on multiple inputs

[Nigel Mcfarlane]

Dear vtkusers,

I am creating a visual pipe in vtk 6.2.0 and I am having problems connecting vtkAppendPolyData to multiple inputs which start from images of different dimensions.  The visual pipe converts a set of input images into isosurfaces, adds scalars for colour and transparency, then merges them into one polydata mesh so they can be depth sorted before rendering.  Its structure looks like this:

//
//     image1       image2       image3
//       |            |            |
//    DMCubes1     DMCubes2     DMCubes3
//       |            |            |
//  AddScalars1  AddScalars2  AddScalars3
//             \      |      /
//              \     |     /
//               \    |    /
//            vtkAppendPolyData
//                    |
//           vtkDepthSortPolyData
//                    |
//               Mapper/Actor
//                    |
//                 Renderer
//

The images are produced by vtkMetaImageReader, the "DMCubes" filters are vtkDiscreteMarchingCubes, and the"AddScalars" filters are my own code.

The problem is that this produces an image in which the dimensions/extents of two of the images have clearly been set incorrectly.  I don't know much about the way the vtk pipeline works, but I suppose that an information request for the extents of the images travels up and back down the pipeline, so the extents get set to that of the last input, and then applied to all the inputs.  The problem disappears if the input branches are first independently updated by calling a manual Update() on each of the AddScalars filters, but it returns if one of the DMCubes filters is modified, which triggers another general update cycle.

Is there any way to set up this pipeline so that it does not require a manual update when the image inputs are modified?

Nigel McFarlane
University of Bedfordshire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20150806/3c07e4ba/attachment.html>