[Insight-developers] Join vertex on QEMeshes

[Thomas Boettger]

Dear Alex,

below you wrote it is just a question of defining a good PointType. I
am not sure if this will be enough. For computing the deformation
easily it would be nice to have easy access to the SimplexPoints and
its SimplexNeighbors. So I have some questions:

1. The SimplexPoints are the centers of the triangles. Can I currently
obtain the coordinates directly or do I need to calculate them?

2. How would I efficiently iterate over the SimplexPoints? The
existing iterators always iterate over the edges (primal or dual).
Currently the dual iterator does not seem too promising as you will
walk over the dual edges. One can of course obtain the cells from
there,  but currently it seems as if I need to verify manually if I
visited a cell already or not (see attached code).

3. I though I could use the DualDataType in the Meshtraits:

  typedef itk::QuadEdgeMeshTraits<double,3,double,SimplexMeshPoint,double,
double> SimplexMeshTraits;

       ^^^^^^^^^^^^^^^
But these values will be assigned to the dual edges and I need the
SimplexPoints properties being assigned to each SimplexPoint and not
an edge. Would I need to use the CellData instead?

I think these are the two most important issues right now. Once I can
iterate of the triangle centers directly and assign 'properties' to
each of them I should be able to adapt the deformation algorithm in a
very short time. After making it work with the qe meshes I think we
should consider a little re-design of the deformation filter itself.

Let me know if your are able to setup shared svn access. For now I
think its fine if I experiment a little bit and keep you updated. Do
you have any milestones, release dates planned?

Find attached the code where I tried to iterate over the dual edges
(plus the old one from Monday). I am also interested in the Decimation
classes you talked about. Will those be checked in to the ITK-CVS
soon?


  Best regards,

    Thomas



On Thu, Jun 26, 2008 at 2:37 PM, Alexandre GOUAILLARD
<alexandre_gouaillard at hotmail.com> wrote:
> Hi thomas,
>
> Let's copy the developer list to have more feedback.
>
> On 6/26/08 5:07 AM, "Thomas Boettger" <tboettger at googlemail.com> wrote:
>
>> Hi Alex,
>>
>> thanks for the quick response. I will test this. The decimation
>> framework sounds interesting. I would be great if I would be able to
>> implement my own decimation criteria based on you new code.
>>
> That's the idea behind the framework. The criterion is a functor, you can
> then come up with your own criterion and use the framework.
>
>> Did you also discuss changes for the SimplexMesh classes.
> Not yet. My guess is that it's something that the 3 of us (with leila)
> should lead, with discussion with the community or at least with copy to the
> mailing list and (silent) approval from the com..
>
>> I think the
>> mesh class could could almost be discarded, but I guess ITK wants to
>> keep it for backwards compatibility.
> QEMesh is only 2-manifold, itk::Mesh is n-manifold. It will then be up to
> users to decide if they want to use a QE mesh or the itk::Mesh for
> describing their surfaces. Note that for the time being, QE is still slower
> and takes more memory, even though implementation of filters is much easier,
> as you report.
>
>> The deformation filter itself is
>> rather simple as long as you can access each points three neighbors
>> (which is quite simple with the QEmeshes we should be fine.
> Yes, I do not foresee any problem here.
>
>> One open
>> issue is where we should store all the computed values like the
>> barycentric coordinates, normals and so on. This currently is quite
>> messy in the old code.
> It's just a matter of defining the good pointType. We are polishing normal
> and curvature filter which should give good exemples of that.
>
>> I also never really used the contributed classes as I continued
>> developing and changing loads of small things in the deformable model
>> itself, e.g. multi threading, global contraints based on ICP (by
>> incorporating vtk classes), different external force computations and
>> more...
> Well, now is a good time to contribute your changes. The backward
> compatibility of ITK might bite you :-D I would be interested in seing the
> new code. The multithreading in particular interests me.
>
>> So I cannot really tell what the best way would be for future
>> directions. But I am willing to discuss, help and maybe contribute if
>> I can be of any help.
> Let's see if we could have acommon svn access (maybe in the NAMIC sandbox)
> to put the code there and work together on it. What do you say?
>
> Alex.
>
>>
>>
>>   Best,
>>
>>     Thomas
>>
>>
>> On Wed, Jun 25, 2008 at 10:55 PM, Alexandre GOUAILLARD
>> <Alexandre_Gouaillard at hms.harvard.edu> wrote:
>>> Hi thomas.
>>>
>>> Problem solved.
>>> It was indeed because of the points IDs.
>>> I added a method to QEMesh that you should call before you write the mesh"
>>> SqueezePointsIds()
>>>
>>> I added this one line in your code and it works fine (it was thus a
>>> vizualization problem.
>>>
>>> BTW we have a decimation code ready, and we are going to put it in ITK
>>> beofre the end of the week. It's a complete framework, where you can plug
>>> the stop criterion and so on.
>>> We have a dedicated priorty queue for mesh decimation, a decimation engine
>>> (based on JoinVErtex, indeed), an edgelength criterion, and we are polishing
>>> a Quadratic criterion right now.
>>>
>>> Alex.
>>>
>>>
>>> On 6/25/08 12:01 PM, "Thomas Boettger" <tboettger at googlemail.com> wrote:
>>>
>>>> ---------- Forwarded message ----------
>>>> From: Thomas Boettger <tboettger at googlemail.com>
>>>> Date: Wed, Jun 25, 2008 at 5:59 PM
>>>> Subject: Join vertex on QEMeshes
>>>> To: alex Gouaillard <AGouaillard at slb.com>, baghdadi at sickkids.ca
>>>>
>>>>
>>>> Hi Alex and Leila,
>>>>
>>>> I started experimenting with the QEMesh classes (ITK 3.6.0).
>>>>
>>>> And ran into the following problem:
>>>>
>>>> 1. I load a vtk mesh
>>>> 2. Call JoinVertexFunction for an arbitrary edge (look through the
>>>> input vtk file in a text editor and choose one line.
>>>> 3. Store the mesh
>>>>
>>>> I expected to see a correct output mesh (with one point less and all
>>>> edges and faces correct), but when I load both, input and result to
>>>> paraview the result looks corrupted.
>>>>
>>>> You can use the source code in the attached zip file to reproduce it.
>>>> Just ignore all lines of code besides the main function...
>>>>
>>>> I also attach you the mesh I used for the testing (smallMesh.vtk) and
>>>> the result (result.vtk).
>>>>
>>>> cmd line inputs were:
>>>> $ /cygdrive/d/devel/QEMeshTests/bin/release/JoinVertexTest.exe
>>>> smallMesh.vtk result.vtk 0 3
>>>>
>>>> I am not sure what is going wrong. Maybe I did not understand the
>>>> JoinVertex operator and need to take care of face corrections myself
>>>> after deleting the point?
>>>>
>>>> Help is welcome...
>>>>
>>>>
>>>>  Best regards,
>>>>
>>>>    Thomas
>>>
>>>
>>>
>
>
>