I wanted to preserve a discussion that Joachim recently initiated. Basically he encountered unexpected behavior when invoking GetCellEdgeNeighbors() (see attached figure from Joachim). Basically, triangle C is returned as a neighbor to triangle A edge(0,1).
Note that the documentation of vtkDataSet::GetCellNeighbors() and the specialized method vtkPolyData::GetCellEdgeNeighbors() reads something like:
"Topological inquiry to get all cells using list of points exclusive of the cell specified (e.g., cellId). Note that the list consists of only cells that use ALL the points provided."
So it produces the results as documented, but in cases where you have concave, or self-intersecting (non-compatible meshes) cells you may see unexpected results.
+ Similar cases can be found for face neighbors using GetCellNeighbors()
+ The other concept that needs to be brought out I think we can call "symmetry". Given two cells A and B, with E an edge of A. If the neighbor N(A,E) = B, and N(B,E) = A then the neighbor operation is symmetric. However if the cell B has no edge E, then the symmetry property fails. In other words, the intersection of A∩B must contain E (I'm not sure symmetry is the right term, we have to think about this.) I think we can show that for convex, non-intersecting (i.e., compatible) meshes, the neighbor operation is symmetric.
There are a couple of approaches to addressing this: adding new methods, changing the behavior of the old one, modifying filters like feature edges to be symmetry aware (it would be a fun addition) etc. Longer term if VTK is to be used more for explicit geometric modelling (as compared to volumetric/implicit modeling) then better data structures and API are probably needed.
AFAIK this is in the mulling stage. Of course any feedback and comments are encouraged.
William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 [hidden email] http://www.kitware.com (518) 881-4902
Powered by www.kitware.com