[vtk-developers] Is this a bug in vtkGeometryFilter?

[John Biddiscombe]

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
> vtk-developers at vtk.org
> 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:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82