[vtkusers] [NonLinearSubdivisionLevel] issue with quadratic meshes related to non-symmetric rotating triangulation algorithm
Eloi Gaudry
Eloi.Gaudry at fft.be
Fri Jan 10 08:19:06 EST 2014
Here is a patch to restore the correct behavior with quadratic cells.
Note that it also contains some cherry picked patch from recent commits.
Eloi
-----Original Message-----
From: vtkusers-bounces at vtk.org [mailto:vtkusers-bounces at vtk.org] On Behalf Of Eloi Gaudry
Sent: jeudi 9 janvier 2014 16:23
To: John Platt; Gregory Lielens
Cc: vtkusers at vtk.org
Subject: Re: [vtkusers] [NonLinearSubdivisionLevel] issue with quadratic meshes related to non-symmetric rotating triangulation algorithm
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
>>
>>
>
>
>
>
_______________________________________________
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_vtk.diff
Type: application/octet-stream
Size: 20860 bytes
Desc: patch_vtk.diff
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140110/d6066244/attachment.obj>
More information about the vtkusers
mailing list