Is this a bug in vtkGeometryFilter?

[Wilson, Andrew T]

I'm using vtkGeometryFilter to turn the output of vtkThreshold back into
a vtkPolyData.  The filter input happens to have both VTK_VERTEX and
VTK_LINE cells.  There's no clipping at all going on, no point
selection, nothing like that -- the intent is just to transmogrify the
vtkUnstructuredGrid into a vtkPolyData.  With that as background, the
problem is that the cell data for the VTK_VERTEX cells gets lost.  The
cells themselves are copied over.

Take a look at Graphics/vtkGeometryFilter.cxx starting around line 730.
I'm concerned about the arguments to the calls to
outputCD->CopyData(...).  Since Verts, Lines, Polys, and Strips are
brand new vtkCellArrays, the 'newCellId' variable will in each case how
many cells /of that particular type/ have been added.  The effect, I
believe, is that cell data for the different cell types will clobber one
another.  Consider this example:

You've got a vtkUnstructuredGrid with 2 cells: one VTK_VERTEX, one
VTK_LINE.  You run it through vtkGeometryFilter with its default
settings.  When you get down to this chunk of code, the VTK_VERTEX will
get newCellId = 0 and copy the cell data into location 0 of the output
cell data.  Then, when you handle the VTK_LINE, you will /once again/
get newCellId = 0 because it's the first cell of type VTK_LINE.  This
will clobber the cell data for the VTK_VERTEX cell already in position
0.

Am I overlooking something or is this a real bug?  I haven't looked at
the other Execute methods: it seems like the same problem could occur
elsewhere as well.

I think this would probably have to be fixed using a two-pass approach.
First, copy all the cells from the input to the output.  Keep track of
the mapping from input cell ID to cell IDs in each of the output cell
arrays.  Then, go back through the data once again and copy all of the
cell data over.  This imposes some additional memory overhead,
especially for the quadratic cells, but is the simplest scheme I can
think of offhand.

If this turns out to be a real bug I'll put it into the bug tracker.
Please let me know if I've misunderstood.

-- Andy



_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers

[Biddiscombe, John A.]

I haven't looked at the code, but I'd be pretty sure that it's a real
bug. Many filters don't get the verts/lines/polys/strips cell ordering
correct when copying/creating new cell data or arrays from inputs. If
you step through the code and the CellId's are being duplicated then it
is a real bug. Storing the cellId's on the first pass in special lists
and then resorting will work.

JB


Wilson, Andrew T wrote:

> I'm using vtkGeometryFilter to turn the output of vtkThreshold back into
> a vtkPolyData.  The filter input happens to have both VTK_VERTEX and
> VTK_LINE cells.  There's no clipping at all going on, no point
> selection, nothing like that -- the intent is just to transmogrify the
> vtkUnstructuredGrid into a vtkPolyData.  With that as background, the
> problem is that the cell data for the VTK_VERTEX cells gets lost.  The
> cells themselves are copied over.
>
> Take a look at Graphics/vtkGeometryFilter.cxx starting around line 730.
> I'm concerned about the arguments to the calls to
> outputCD->CopyData(...).  Since Verts, Lines, Polys, and Strips are
> brand new vtkCellArrays, the 'newCellId' variable will in each case how
> many cells /of that particular type/ have been added.  The effect, I
> believe, is that cell data for the different cell types will clobber one
> another.  Consider this example:
>
> You've got a vtkUnstructuredGrid with 2 cells: one VTK_VERTEX, one
> VTK_LINE.  You run it through vtkGeometryFilter with its default
> settings.  When you get down to this chunk of code, the VTK_VERTEX will
> get newCellId = 0 and copy the cell data into location 0 of the output
> cell data.  Then, when you handle the VTK_LINE, you will /once again/
> get newCellId = 0 because it's the first cell of type VTK_LINE.  This
> will clobber the cell data for the VTK_VERTEX cell already in position
> 0.
>
> Am I overlooking something or is this a real bug?  I haven't looked at
> the other Execute methods: it seems like the same problem could occur
> elsewhere as well.
>
> I think this would probably have to be fixed using a two-pass approach.
> First, copy all the cells from the input to the output.  Keep track of
> the mapping from input cell ID to cell IDs in each of the output cell
> arrays.  Then, go back through the data once again and copy all of the
> cell data over.  This imposes some additional memory overhead,
> especially for the quadratic cells, but is the simplest scheme I can
> think of offhand.
>
> If this turns out to be a real bug I'll put it into the bug tracker.
> Please let me know if I've misunderstood.
>
> -- Andy
>
>
>
> _______________________________________________
> vtk-developers mailing list
> [hidden email]
> http://www.vtk.org/mailman/listinfo/vtk-developers
>  

--
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre  | Tel:  [phone]
Via Cantonale, 6928 Manno, Switzerland      | Fax:  [phone]


_______________________________________________
vtk-developers mailing list
[hidden email]
http://www.vtk.org/mailman/listinfo/vtk-developers