[Insight-users] 4-Connectivity of itkMesh (load a PTX file)?

[David Doria]

On Sun, Aug 9, 2009 at 3:28 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:

> Hi David,
>
>
> Thanks for the list of algorithms.
>
>
> Please find some comments below.
>
>
> 1) This one is a challenging one. I agree with you that Octrees
>      or a KdTree will be helpful here.
>
>
> 2) We do search for closest points in the code
>     recently posted to the Insight Journal:
> http://www.insight-journal.org/browse/publication/645
> http://hdl.handle.net/10380/3063
>
> This is done in the source code of the MeshInterpolator.
>
> You will also find the code at:
>
> http://svn.na-mic.org/NAMICSandBox/trunk/QuadEdgeMeshRigidRegistration/Source/
>
> You will see that the code uses a KdTree internally.
>
>
> 3) Agree
>
> 4) Agree
>
> 5) It wouldn't be too hard to extend Region Growing algorithms
>     to work on Meshes. They will have to be independent classes
>     but will be easily build once we port a Mesh version of the
>     FloodFill iterator.
>
>
> Coming up with a hybrid data structure sounds like a good
> idea. In this way the different needs could be balanced
> without having to force the functionality of an existing data
> structure.
>
> Have you had a chance to study the VTK classes ?:
>
>               vtkStructureGrid
>               vtkUnstructureGrid
>
>
> They will be a good reference.
>
>
>          Luis
>

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?

2) Great, got the kd-tree working, thanks.

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.

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
GetCellNeighbors<http://www.itk.org/Doxygen/html/classitk_1_1Mesh.html#5a80aa40a37e21266f23e65f83f7e942>.
 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".

Thanks,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090813/c5c9270a/attachment-0001.htm>