<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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).</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Note that the documentation of vtkDataSet::GetCellNeighbors() and the specialized method vtkPolyData::GetCellEdgeNeighbors() reads something like:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">"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."</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Other notes:</div><div class="gmail_default" style="font-family:verdana,sans-serif">+ Similar cases can be found for face neighbors using GetCellNeighbors()<br></div><div class="gmail_default" style="font-family:verdana,sans-serif">+ 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.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">AFAIK this is in the mulling stage. Of course any feedback and comments are encouraged.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Best,</div><div class="gmail_default" style="font-family:verdana,sans-serif">Will</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>William J. Schroeder, PhD<br>Kitware, Inc. - Building the World's Technical Computing Software<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br><a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br>(518) 881-4902</div></div></div></div>