[Insight-developers] Re: itkQuadEdgeMesh Review

Wed Dec 20 10:17:15 EST 2006

Hi Luis,

I would like to make all the new classes directly useful for the user  
available in WrapITK before the release.
I see several reasons to do that:
  (a) be sure that the API is usable with the wrappers
  (b) increase the code coverage of WrapITK
  (c) be sure that everything builds with various template parameters

Of course, I would be pleased to work on that.

Please let me know what you think about that, and how we can proceed if  
you agree with that.

Thanks,

Gaetan

On Wed, 20 Dec 2006 14:50:41 +0100, Luis Ibanez <luis.ibanez at kitware.com>  
wrote:

>
>
> 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.
>>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr