[Insight-developers] Re: itkQuadEdgeMesh Review

[Luis Ibanez]

Hi Alex, Thomas, Leila,


Sylvain Jaume will be in charge of moving the
itkQuadEdgeMesh and associated classes into ITK.

He will be reviewing the coding style and the
class hierarchy when he returns from vacations
(in January).

Presumably we will do this progressively. As you
know, it takes several days to get a single class
to compile correctly in all platforms. So, what
may be a matter of hours when working in a single
platform (Let's say only Linux or only Windows)
becomes a couple of days when we have to clear up
the code for all the compilers that we are supporting
{ICC, Gcc, VS, Borland} and different OS {MacOS, IRIX,
Solaris, Linux, Windows, Cygwin, MinGw}.

With the highly templated structure of the Mesh classes,
this task is not trivial.


I would suggest that we focus first in getting the
data structures right, and then we move into adding
Mesh filters to the toolkit.



    Regards,


        Luis



-----------------------------
Alexandre Gouaillard wrote:
> hi thomas.
> 
> 
>>What is the decision for including the meshes into
>>ITK3.2 and if it is positive in what form will it be included?
>>Extended or as is?
> 
> 
> extended.
> 
> 
> 
> 
> 
>>The classlist gives me more than 60
>>types, so what do you think about introducing groups, something like
>>SurfaceMeshDataStructures, SurfaceMeshAlgorithms,
>>SurfaceMeshOperators, Iterators...? Its just an idea.
> 
> 
> Good idea. How could we do that? Is this just a naming convention you are thinking about (like creating a namespace) or creating an abstract layer ala vtkPolyDataAlgorithms
> Note that abstract layers exist already most classes inherits from those two:
> itk::MeshToMeshFilter  ==> itkQE::MeshCopy (should be renamed)
> itkQEMeshFunctionBase ==> all operators including eulers (design need to be explained more in detail).
> 
> 
> 
> 
> 
>>I did not try to implement something, but will start
>>in January. So I might have loads of other questions soon.
> 
> 
> You're more than welcome.
> 
> 
> 
> 
>>Specific questions:
>>
>>Q1: Could I just define itk::RegularSphereMeshSource with <itkQEMesh>
>>and would this give me a QEMesh as output or do I need to write a new
>>one similar to the CylinderMeshSource? Or could I create the old
>>ITKMesh input it into some filter and simply output the QEMesh?
>>
> 
> 
> Q1.1 could I definie MySurfaceFilter<itkQEMesh>?
> yes, and it should be faster. 
> 
> Q1.2 What would be the output type, itkMesh or itkQEMesh?
> Output would be as defined within the implementation (sometimes itkMesh is hardcoded, sometimes output type in same as template parameter).
> 
> Q1.2 Do I need to write my own filter?
> you do NOT need to if it deals with SURFACES, but filter taking into account QEmesh features would be easier to code, implementation should be smaller, code should be faster. specific local iterators and euler operators simplify greatly the design, even if you can write everything following the old itkMesh style. if you want your filter to be n-dimensional, no itkQE.
> 
> 
> 
> 
> 
>>Q2: Was the reimplementation of the cross product necessary? And why
>>doess it hide in a file named itkQEMeshParamMatrixCoefficients.h?
>>
> 
> 
> Q2 Was he reimplementation necessary?
> there was reason for that (which I don t remember in detail but i could dig them in team reports). Anyway, the parameterization classe are not mature enough and should be removed from the tarball to be integrated in ITK 3.2.
> 
> 
> 
> 
> 
>>Q3: Don't you think Doxygen should explain the meaning of "Geometrical
>>Iterator"?
>>
> 
> Yes, will do.
>  
> 
> 
> 
> 
>>Q4: Regarding QEPoint: What is the meaning of the return value of
>>'IsInternal()' in QEPoint? And what exactly does the method GetEdge()
>>return? Could you please change the spelling of 'Initialise()'  to
>>Initialize().
>>
> 
> 
> Q4.1 Meaning of internal ?
> Point which is not on a border = point whose edges in the Oring are not border edges.
> 
> Q4.2 What exactly the method GetEdge() returns?
> a QEPrimal which is the type of a primal edge as compared to the type of a dual edge.
>  
> Q4.3 Initialize() spelling typo?
> will do.
> 
> 
>>Q5:Could you please improve documentation for itkQE::MeshWithDual?
>>
> 
> Hum, not for the time being. iT will be removed from the tarball as long as the discussion on the design of the containers of the dual geometry is not over. This class implements a brute force approach,. It is a good feasbility prototype, but a bad design. It will be address this wednesday.
>  
> 
> 
> 
> 
>>Q6: Could you create a  'How to create a Mesh'-  or a 'IO' section and
>>link it on the main page (similar to the 'Global traversing...'). I
> 
> 
> Yes. It exists in the documentation you have under the "related pages" and "navigating back and forth ..." link. We will improve the documentation to send the reader to the "QEMeshToVTKUnstructuredGrid", "vtkToItkQEImport", "vtkUGToItkQEImport" examples and related tests.
> 
> 
> I am back to france for a few weeks, and thus we resume the usual QEbab dinner and coding parties on wednesday nights. I'll get back to you with an updated version on wednesday, possibly with a new tarball for the insight journal.
> 
> cheers,
> 
> alex.
> 
> 
>