[vtkusers] [NonLinearSubdivisionLevel] issue with quadratic meshes related to non-symmetric rotating triangulation algorithm
Eloi Gaudry
Eloi.Gaudry at fft.be
Thu Jan 9 09:38:41 EST 2014
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