[Insight-developers] Change suggestions for itkVTKPolyDataWriter and Simplex Meshes

[Alexandre GOUAILLARD]

Hi,

> Dear Alex,
> 
> I modified the code of the itkVTKPolyDataWriter class slightly for two
> reasons:
> 
> 1. I did not have you CVS patch for the point id squeezing. So I
> introduced a runnning index at take the empty points into account
> during save time. This work for
> 
Yes, this was the solution suggested by Jim miller, and it works fine
indeed. I had other reasons to use squeeze, and it was a way for me to kill
two birds with one stone. Your modification is also good, and worth
intergrating in the writer.

> 2. I wanted to use the writer for storing simplex meshes and found it
> was working for triangle meshes only as you assumed all cells being
> triangles when writing the total number of polygon ids:
> 

I decline all responsibility :-D
This class has not been writen by me originally, and it purpose was to be
the lightest reader/writer possible, hence the triangle only. I will check
it, but I think arnaud gelas had already made it polygon-aware in the CVS.
Anyway, thanks for the comtribution, if it's not in the cvs , I will add it.

[...]

> 
> 2.Simplex Meshes:
> I furthermore adapted my deformation classes to run one a TriangleMesh
> without explicit conversion. The deformation filter will take care of
> creating all simplex mesh relationships necessary for the deformation
> algorithm internally and update the original triangle mesh in
> ComputeOutput. I did this as a proof of concept and it works. I will
> send you the code sometime next week.
> 
Is it based on QuadEdgeMesh, or on Mesh?

> I am still not sure what would be the best way of porting the simplex
> mesh deformation algo.
> 
> In general I do believe it is better to have a stric separation, i.e.
> convert to simplex mesh -> deform -> store simplex mesh or -> convert
> to triangle mesh -> store triangle mesh.
> 
I believe that if it can be made automatic and transparent to the user, it
should.

> On the other hand I showed with my latest implementation tests one can
> completely ignore the simplex meshes and only use the deformation
> algorithm hiding the dual simplex mesh representation from the user
> completely.

Indeed.
> 
> Furthermore those simplex meshes look so nice I think one should not
> try hide them from a user in clincal applications visualization parts
> :-)

Agreed. But it's then just a matter of extracting it for vizualization then.
> 
> Well there is loads of thing which need to be discussed. Maybe we
> should start putting together a document discussing the different
> options and pros & cons before a decision can be made.
> 
What about a wiki page on the itk wiki?

Alex.