Hi David,<br><br><br>A) The method for getting all the neighbors of a node in the QuadEdgeMesh is:<br><br> for( unsigned int pointId = 0; pointId < numberOfPoints; pointId++ )<br> {<br> const OutputPixelType & centralPixelValue = pointData->GetElement( pointId );<br>
<br> const EdgeType * edgeToFirstNeighborPoint = outputMesh->FindEdge( pointId );<br> const EdgeType * edgeToNeighborPoint = edgeToFirstNeighborPoint;<br><br><br> do<br> {<br> const OutputPointIdentifier neighborPointId = edgeToNeighborPoint->GetDestination();<br>
const OutputPixelType & neighborPixelValue = pointData->GetElement( neighborPointId );<br><br> edgeToNeighborPoint = edgeToNeighborPoint->GetOnext();<br><br> // Do your processing here...<br>
}<br> while( edgeToNeighborPoint != edgeToFirstNeighborPoint );<br><br> }<br><br><br><br>B) Notice that the itkQuadEdgeMesh is designed to represent<br> a 2D manifold embedded in a 3D space. I presume that<br>
this is suitable for LiDAR data.... but just in case, it is good<br> to point it out.<br><br><br><br> Regards,<br><br><br> Luis<br><br><br>---------------------------------------------------------------------------------<br>
<div class="gmail_quote">On Thu, Aug 13, 2009 at 3:50 PM, David Doria <span dir="ltr"><<a href="mailto:daviddoria%2Bitk@gmail.com">daviddoria+itk@gmail.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;">
<br><div class="gmail_quote"><div class="im">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></div>
<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><div><div></div><div class="h5">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></div></div></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>
<br>_____________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at: <a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
<br></blockquote></div><br>