[Insight-developers] Join vertex on QEMeshes

[Alexandre GOUAILLARD]

Hi thomas,

M_NoPoint is defined as vcl_numeric_limits< OriginRefType >::max()
In itkGeometricalQuadEdge.txx
It should not be 0.

I never met this case, I will to make a code that deletes the cell #0
(should always be an edge BTW) and see what happen.

Thanks,

Alex.

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

> Alex,
> 
> one more thing:
> 
> I found the following lines of code which do worry me a little bit:
> 
> itkQuadEdgeMesh::LightWeightDeleteEdge(...) (around Line 900)
> 
>   CellIdentifier LineIdent = e->GetIdent( );
>   if( LineIdent != m_NoPoint )
>     {
>     EdgeCellType* edgeCell = dynamic_cast< EdgeCellType* >(
> this->GetCells( )->GetElement( LineIdent ) );
>     this->LightWeightDeleteEdge( edgeCell );
>     }
>   else
>     {
>     itkDebugMacro( "Edge Not found. LineIdent not set?" );
>     return;
>     }
> 
> Here you compare the LineIdentifier to m_NoPoint. In my version
> m_NoPoint is defined as 0. For the very first edge
> FindFirstUnusedCellIndex() will return 0 as well.
> 
> Then I cannot delete the edge added first. This will of course stop
> the JoinVertex function from working for this first edge. The edge is
> not deleted and then the point is not isolated and cannot be deleted.
> 
> Is this problem know already? May be you can use
> 
>   NumericTraits<unsigned long>::max()
> 
> instead ?
> 
> In my own decimation I unfortunately always tried to join the vertices
> of this first edge and was wondering why the point count was not
> decreasing.
> 
> 
>   Best regards,
> 
>     Thomas
> 
> 
> 
> On Thu, Jun 26, 2008 at 11: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.
>> 
>> Did you also discuss changes for the SimplexMesh classes. I think the
>> mesh class could could almost be discarded, but I guess ITK wants to
>> keep it for backwards compatibility. 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. 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.
>> 
>> 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...
>> 
>> 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.
>> 
>> 
>>  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
>>> 
>>> 
>>> 
>>