[vtkusers] VTK Roadmap

[Will Schroeder]

Hello Luca-

At 10:38 AM 3/19/2003 -0500, lucantiga at softhome.net wrote:
>Hi Will,
>  I found the point about the rearrangment of vtkPolyData and
>vtkUnstructuredGrid into a more general vtkMesh very attractive (along
>with the integration of STL and templates) (towards itk compatibility?).
>How far are we from there?

Nothing will happen for at least a year.

>  I also have a more general question.
>  Once the above steps will be taken, do you envision some evolution (of
>vtk, itk or ?tk) towards some application-oriented computational geometry
>classes (e.g. for shape analysis)? Although the itkMesh framework is
>promising, Itk is explicitly geared towards registration and segmentation
>(although you could think about some part of shape analysis as to some
>kind of segmentation performed on a mesh).

The original VTK vtkPolyData and vtkUnstructuredGrid classes were designed 
as a "read-only", relatively simple data structure to represent and display 
meshes. It seems that a lot of people want to use them for computational 
geometry (surprise!). One of the problems with this is that it is hard to 
do complex editing in an efficient way. The ITK mesh is designed to be 
editable, but there is a penalty in memory and speed because of the 
instantiation (per cell) and pointers, The nice thing about ITK's mesh is 
that it is possible to represent intermediate cell boundary (faces, edges) 
information in an adaptive way. However, the data model (i.e., attributes) 
is less dynamic than I'd like because of the templates. It is possible that 
these may move closer together in some ways, but the opposing design goals 
(memory, transport efficiency vs. editable, rich topological structure) may 
be hard to resolve and we may end up with separate structures.

>PS: I know there are valid tools explicitely devoted to computational
>geometry (eg CGAL), but shape analysis (expecially in the medical field)
>must also itegrate differential geometry and image processing, so a more
>integrated framework is needed. Maybe some wrapping of CGAL classes (as
>for vnl in Itk)?

CGAL is a beastie from what I understand. I don't see that happening 
anytime soon.

Will