[vtkusers] [NonLinearSubdivisionLevel] issue with quadratic meshes related to non-symmetric rotating triangulation algorithm

Eloi Gaudry Eloi.Gaudry at fft.be
Thu Jan 9 10:23:10 EST 2014


You can use Paraview 4.x for instance, it's built against VTK-6.
According to the official documentation, internal faces shared between cells will not be displayed, thus I think there is a bug.
Regards,

-----Original Message-----
From: John Platt [mailto:jcplatt at dsl.pipex.com] 
Sent: jeudi 9 janvier 2014 16:21
To: Eloi Gaudry; Gregory Lielens
Cc: vtkusers at vtk.org
Subject: Re: [vtkusers] [NonLinearSubdivisionLevel] issue with quadratic meshes related to non-symmetric rotating triangulation algorithm

Hi Eloi,

I don't have a viewer built with 5.10 which will let me do this. I am using vtkMDI which is part of the samples.

If internal faces are present, I would expect to see the triangulation of each of these in the wire frame view.

I seem to recall that VTK does not tolerate reflection or inversions of the topology of 3d cells. I check whether a cell is right or left handed and adjust the topology accordingly.

HTH

John.

----- Original Message -----
From: "Eloi Gaudry" <Eloi.Gaudry at fft.be>
To: "John Platt" <jcplatt at dsl.pipex.com>; "Gregory Lielens" 
<Gregory.Lielens at fft.be>
Cc: <vtkusers at vtk.org>
Sent: Thursday, January 09, 2014 2:38 PM
Subject: RE: [vtkusers] [NonLinearSubdivisionLevel] issue with quadratic meshes related to non-symmetric rotating triangulation algorithm


> John,
>
> You need to look at the Surface (with edges or not) view, with an 
> opacity value around 0.60 for instance.
> Look at the shared face between the wedge and the box.
>
> Eloi
>
> -----Original Message-----
> From: John Platt [mailto:jcplatt at dsl.pipex.com]
> Sent: jeudi 9 janvier 2014 15:13
> To: Gregory Lielens
> Cc: Eloi Gaudry; vtkusers at vtk.org
> Subject: Re: [vtkusers] [NonLinearSubdivisionLevel] issue with 
> quadratic meshes related to non-symmetric rotating triangulation 
> algorithm
>
> Hi Greg,
>
> The copying of point global Ids should not affect the visualisation 
> (this is user data - node numbers in my case).
>
> I think the problem you are describing is that VTK thinks your 
> "internal face" is actually two "external" faces. Is this correct?
> I don't see this in a wire frame view of  *_ko.vtk.
>
> John.
>
> ----- Original Message -----
> From: "Gregory Lielens" <Gregory.Lielens at fft.be>
> To: "John Platt" <jcplatt at dsl.pipex.com>
> Cc: "Eloi Gaudry" <Eloi.Gaudry at fft.be>; <vtkusers at vtk.org>
> Sent: Thursday, January 09, 2014 12:39 PM
> Subject: Re: [vtkusers] [NonLinearSubdivisionLevel] issue with 
> quadratic meshes related to non-symmetric rotating triangulation 
> algorithm
>
>
>> Hi John,
>>
>> If I get the sides effects you mention correctly, it means that the 
>> way duplication of cell nodes is avoided has changed from 5.8 to 5.10:
>> Before, the mechanism was through copy of global ids, so that nodes 
>> belonging to different cells share the same global id and thus not 
>> duplicated, while the new way bypass this copy and rely instead on 
>> geometric coincidence.
>>
>> I understand this should have an impact on performance and memory, 
>> but I think it is not directly related to the problem we have here 
>> (coincident nodes ends up merged or not duplicated in the first 
>> place). This is coherent with the fact that the first example do not 
>> exhibit the problem (fake internal face between quad elements), while 
>> the second one does, even if both have the same nodes at the same 
>> position.
>>
>> I think the problem is inherent to the face splitting algorithm: What 
>> VTK do now is to split quadratic 8 node faces into 4 corner triangles 
>> and 2 internal triangle, which do not add nodes. Problem is that it 
>> breaks face symmetry (4order symmetry when face is unsplitted, i.e.
>> one can choose any of the 4 nodes as first node without changing the 
>> face
>> description) into a 2order symmetry (the 2 center triangles imply 
>> that the 4 sides/corner nodes are not equivalent, 2 sides are // to 
>> the edge linking the 2 center triangles, 2 sides are perpendicular).
>>
>> This means we have no garantee that the splitted mesh is correct, if 
>> one element split its quadrangle face in one way and it's neighbor in 
>> the other way, the splitted mesh becomes non congruent and internal 
>> boundary faces appear.
>>
>> There is two way imho to solve this problem:
>> -garantee a face is always splitted in the same way.
>> -add a center node so that a quadratic quadrangle face is splitted 
>> into
>> 4 corner triangles and 4 center triangles. This way the splitted face 
>> keep an order 4 symmetry and no internal face will appear.
>>
>> IF the second way is choosen, the new method to avoid duplicated 
>> nodes may be better (using geometrical coincidence), as it will merge 
>> the new center node even if it does not have global id....
>>
>> Best regards,
>>
>> Greg.
>>
>>
>> On jeu, 2014-01-09 at 11:43 +0000, John Platt wrote:
>>> Hi Eloi,
>>>
>>> The treatment of quadratic cells in vtkDataSetSurfaceFilter appears 
>>> to have changed between 5.8 & 5.10.
>>>
>>> I have noticed two side effects -
>>>
>>>     1. Point Global Ids are no longer copied.
>>>
>>>     2. Coincident points are ALWAYS merged.
>>>
>>> I have not reported these as bugs yet because I would like to give a 
>>> suitable fix. The sticking point for me is the additional memory 
>>> used by vtkUnstructuredGridGeometryFilter. I would prefer the 
>>> quadratic cells to be treated as in 5.8.
>>>
>>> If you think 2 above may be causing trouble, you could changing 
>>> vtkDataSetSurfaceFilter::UnstructuredGridExecute()...
>>>
>>> uggf->SetPassThroughPointIds(this->PassThroughPointIds);
>>>
>>> uggf->MergingOff(); // ** JCP ** do not merge coincident points
>>>
>>>
>>>
>>> HTH
>>>
>>> John.
>>>
>>> ----- Original Message ----- 
>>>         From: Eloi Gaudry
>>>         To: vtkusers at vtk.org
>>>         Cc: Gregory Lielens
>>>         Sent: Thursday, January 09, 2014 9:40 AM
>>>         Subject: [vtkusers] [NonLinearSubdivisionLevel] issue with
>>>         quadratic meshes related to non-symmetric rotating
>>>         triangulation algorithm
>>>
>>>
>>>         Hi,
>>>
>>>
>>>
>>>         I’m sending a small reproducer (made of a quadratic hexaedron
>>>         element connected to a quadratic wedge ) for the following
>>>         bug : depending on the orientation of the elements, the
>>>         triangulation algorithm failed to delivers an input usable by
>>>         the surface mapper with a NonLinearSubdivisionLevel >=1:
>>>
>>>         -          for a value of 0, the external boundaries are
>>>         displayed correctly,
>>>
>>>         -          for a value of 1, the shared faces/nodes between
>>>         the hexaedron and the wedge is displayed as an external
>>>         boundary (i.e. the shared faces are considered different
>>>         whereas they are based on the same nodes.)
>>>
>>>         -          for a value of 2 and more, the subdivision leads to
>>>         a buggy on-screen representation.
>>>
>>>
>>>
>>>         The first file (*_ok.vtk) will show the expected behavior for
>>>         a NonLinearSubdvisionLevel value of 0 and 1.
>>>
>>>         The second file (*_ko.vtk) will show the incorrect behavior
>>>         for a NonLinearSubdvisionLevel value 1.
>>>
>>>
>>>
>>>         If you look at the subelements used for dividing each faces of
>>>         the hexaedron and the wedge (with a surface mapper and an
>>>         opacity of 0.5 for instance), you will notice a mismatch
>>>         between the ones created on the hexaedron and the ones created
>>>         on the wedge. This leads to an incorrect vizualisation of an
>>>         unshared face between both cells…
>>>
>>>
>>>
>>>         Are you aware of this issue (present in 5.10.1 version at
>>>         least and still there in 6.1.0.rc1) ?
>>>
>>>         Can this easily be fixed (the behavior seen in 5.6.1 is
>>>         correct for a NonLinearSubdivisionLevel value-like of 1) ?
>>>
>>>
>>>
>>>         Regards,
>>>
>>>         Eloi
>>>
>>>
>>>
>>>
>>>
>>>
>>> ______________________________________________________________
>>>
>>>         _______________________________________________
>>>         Powered by www.kitware.com
>>>
>>>         Visit other Kitware open-source projects at
>>>         http://www.kitware.com/opensource/opensource.html
>>>
>>>         Please keep messages on-topic and check the VTK FAQ at:
>>>         http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>>         Follow this link to subscribe/unsubscribe:
>>>         http://www.vtk.org/mailman/listinfo/vtkusers
>>
>>
>
>
>
> 





More information about the vtkusers mailing list