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 |
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: +41 (91) 610.82.07 Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 _______________________________________________ vtk-developers mailing list [hidden email] http://www.vtk.org/mailman/listinfo/vtk-developers |
Free forum by Nabble | Edit this page |