[Insight-developers] Join vertex on QEMeshes

[Alexandre GOUAILLARD]

Hi thomas.

I know this is a tricky question.

Basically, the QEMesh as it is is not enough for simplex, because you need
to have the dual geometry somewhere.
Right now, you have the dual topology (dual cells) for free, but not the
dual topology (what you call the simplexpoint).

The good news is: We have an extension of itkQE that handle dual geometry
that we developped for simplex meshes :)
The bad news is, I did not touch it for a few months, and I don;t know in
which state it is. Let me resurrect it and send it to you.
The Idea is: you use the dual point indent. As DualOrigin type.
You iterate over the dual QE to be on the simplex , and GetOrigin then
return the ID of the **DUAL** point.
This prototpe does not exactly handle a dual point container (nasty),
It does not allow the user to plug it's function to compute the dual point
geometry( nasty) and so on. But it's a good proof of concept, and should
give you a head start.

If you want to iterate over primal cells (dual points) you then have two
ways:
- iterate over the cell container (be carefull of the edges  ...)
- iterate over the dual point container,
- use an itkQuadEdgeMeshFrontIterator (if you use it on primal edge, you
have a dijkstra, dual edge -> a front )

You are right, at this stage we should share a svn rep. It is close to
impossible at Harvard. Is that something you can set up on your side?
Otherwise, we can create our rep. in the namic sandbox (I guess).

We plan to release the decimate code once the quadratic criterion will be
ready (one week?) in Insight Journal. I will send you a snapshot which works
with an edge length criterion tonight for you to evaluate.


On 6/27/08 10:08 AM, "Thomas Boettger" <tboettger at googlemail.com> wrote:

> 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
>>>> 
>>>> 
>>>> 
>> 
>> 
>>