[Insight-developers] Join vertex on QEMeshes

[Alexandre GOUAILLARD]

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




------ End of Forwarded Message