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

Eloi Gaudry Eloi.Gaudry at fft.be
Thu Jan 9 08:01:52 EST 2014


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