<br><div class="gmail_quote">On Sun, Aug 9, 2009 at 3:28 PM, Luis Ibanez <span dir="ltr"><<a href="mailto:luis.ibanez@kitware.com" target="_blank">luis.ibanez@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi David,<br><br><br>Thanks for the list of algorithms.<br><br><br>Please find some comments below.<br><br><br>1) This one is a challenging one. I agree with you that Octrees<br> or a KdTree will be helpful here.<br>
<br>
<br>2) We do search for closest points in the code<br> recently posted to the Insight Journal:<br><a href="http://www.insight-journal.org/browse/publication/645" target="_blank">http://www.insight-journal.org/browse/publication/645</a><br>
<a href="http://hdl.handle.net/10380/3063" target="_blank">http://hdl.handle.net/10380/3063</a><br><br>This is done in the source code of the MeshInterpolator.<br><br>You will also find the code at:<br><a href="http://svn.na-mic.org/NAMICSandBox/trunk/QuadEdgeMeshRigidRegistration/Source/" target="_blank">http://svn.na-mic.org/NAMICSandBox/trunk/QuadEdgeMeshRigidRegistration/Source/</a><br>
<br>You will see that the code uses a KdTree internally.<br><br><br>3) Agree<br><br>4) Agree<br><br>5) It wouldn't be too hard to extend Region Growing algorithms <br> to work on Meshes. They will have to be independent classes<br>
but will be easily build once we port a Mesh version of the <br> FloodFill iterator.<br><br><br>Coming up with a hybrid data structure sounds like a good<br>idea. In this way the different needs could be balanced <br>
without having to force the functionality of an existing data<br>structure.<br><br>Have you had a chance to study the VTK classes ?:<br><br> vtkStructureGrid<br> vtkUnstructureGrid<br><br><br>They will be a good reference.<br>
<br><br> Luis<br></blockquote><div><br>1) The itk::Octree doesn't seem to have any line intersection functions. However, even better than an octree seems to be a modified BSP tree - there was just one added to vtk and it sped up my mesh/ray intersections almost 50x !! Should we port it to ITK? I never know where the overlap between ITK and VTK should stop... can anyone explain a bit more about that?<br>
<br>2) Great, got the kd-tree working, thanks.<br><br>5) There seems to be a decision here as to use a "grid mesh" (i.e. a mesh generated by uniform spherical sampling (like from a LiDAR scanner) has the same 4 (or 8) connectivity as an image would, just that the "pixels" live on a 2d surface embedded in 3d instead of on a flat "image plane") , versus using a general mesh. It may be nice to have a flood fill operator on a general mesh though, and then the "grid mesh" would be handled automatically.<br>
<br>
Is there a way to get all the neighboring points of a point in an itk::Mesh? It looks like itkQuadEdgeMesh may have just about replaced itk::Mesh (all of the existing features + many more). In the quad edge mesh paper the claim you can access neighboring vertices of a vertex, but on the class documentation page I only see <a href="http://www.itk.org/Doxygen/html/classitk_1_1Mesh.html#5a80aa40a37e21266f23e65f83f7e942" target="_blank">GetCellNeighbors</a> .
Am I missing the GetVertexNeighbors?? There doesn't seem to be any examples of the QuadEdge (particularly traversal over neighboring vertices) in src/Examples - has anyone done this? Maybe someone can add examples like this to the /Examples directory? The mesh flood fill would just be doing this but "tagging" vertices along the way - just like the image flood fill but replacing "visit my 4 neighbors and recurse" with "visit all of my mesh neighboring vertices and recurse".<br>
<br>Thanks,<br><br>David<br>
</div></div>