[vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter

Andreas Buykx A.Buykx at tnodiana.com
Fri Apr 3 08:06:28 EDT 2015


Hi,

All non-linear wedges have the same ordering of face points, causing their normal to point inward.
 
Creating the wedge inside-out seems to work for the vtkUnstructuredGridGeometryFilter (UGGF) issue, but wouldn't this have side effects in routines in vtkCell or vtkCell3D, e.g. when interpolating, contouring,  etc?

>From code inspection I found out that for all wedges, the only method that uses the face point ordering array is the method IntersectWithLine, and that method seems to be independent of the orientation of the face. Changing the three methods that return the face points (GetFace and GetFaceArray) to return properly ordered faces would therefore have the same net result as changing the order of the points in the faces array. In both cases all direct and indirect clients (including UGGF) of these methods may produce different results. However, these differences in results, if any, are for the better I would say. For example it may not be necessary anymore to correct normals since they are already oriented consistently ;-).

As for documentation, the documentation of vtkWedge does not mention anything specific about the orientation of face points or face normals, nor does the vtkCell3D or vtkCell. Also, I couldn't find any definitions of how face normal are supposed to be oriented in the books (toolkit ed.4, user's guide ed.11). 

I created a topic in my repository and made the necessary changes in all wedge classes. The tests that are mentioned for these classes succeed (cells.py fails because I have no VTKData, and TestCellCentersPointPlacer spits out some xml related to DartMeasurement which seems not related to the wedge test). Note that TestCellCentersPointPlacer creates an inverted wedge.

How do we proceed?

Kind regards,
Andreas

________________________________________
From: John Platt [jcplatt at dsl.pipex.com]
Sent: Wednesday, April 01, 2015 10:09 PM
To: Berk Geveci; Andreas Buykx
Cc: vtk-developers at vtk.org
Subject: Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter

Hi,

I think this is also a problem for vtkDataSetSurfaceFilter when mixing
quadratic hex's & wedges. If the actor opacity is reduced, the internal
faces between the hex's & wedges are visible.

This can be fixed by turning the wedge inside-out i.e. swapping points 1
& 2 and 4 & 5. The FE system I work with allows both right and left
handed elements so the topology of each element must be checked and
inverted if necessary.

I agree that the order of the nodes in the face arrays should be changed
to be consistent with the other cells. I suspect this would largely go
unnoticed given the time this inconsistency has been present and the
number of reports on the behaviour.

Thanks,

John.



On 01/04/2015 16:42, Berk Geveci wrote:
> Hi Andreas,
>
> Changing the ordering of vtkWedge would be a very large undertaking
> given that there is years of documentation, file formats (in VTK and
> 3rd party), code etc. that depend on a certain ordering. One less
> intrusive way would be to change any vtkWedge methods that returns
> faces to return them in a different order. I suspect this option is
> doable but I'd like to hear from the community. The least intrusive
> options is to fix the few filters that have this issue but I feel like
> it is a band-aid.
>
> Best,
> -berk
>
> On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx <A.Buykx at tnodiana.com> wrote:
>> Hi,
>>
>>
>>
>> To detect if coinciding faces of neighbouring 3D cells are connected,
>> vtkUnstructuredGridGeometryFilter walks the points of these faces in
>> opposite directions and expects the point ids to match. This fails for
>> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by the
>> python script I attach. The root cause is that the vtkWedge::GetFaceArray
>> and vtkWedge::GetFace return the face points in an ordering that makes the
>> face normal point into the 3D cell instead of out of the  3D cell, like all
>> other 3D cells do. The two other algorithms that generate surface cells
>> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don't suffer from this
>> ordering because the former checks point ordering but explicitly allows both
>> loop directions, and the latter only takes cell connectivity into account
>> without checking point-ordering at all.
>>
>>
>>
>> I don't know what the reason is to have a different face-point ordering for
>> the vtkWedge, but one of the other consequences is that the outer surface
>> will have inconsistent cell normals as can easily be seen when loading the
>> xml files produced by the tests in paraview, and showing the cell normals.
>> So I would prefer to change the face-point ordering in vtkWedge. If that is
>> not possible for some reason then I propose to make/update the case-blocks
>> in the surface filters cell-type switches to re-order the face-points for
>> the wedge faces. As long as this is not dealt with our FEA models will show
>> edges where they should not be so I will have to solve this issue one way or
>> another, and I'd like to contribute it to VTK as well.
>>
>>
>>
>> Shall I make a mantis issue for this? Who can help me with the git/gerrit
>> stuff?
>>
>>
>>
>> Thanks a lot,
>>
>> Andreas Buykx
>>
>> ____________________________________________________________
>> TNO DIANA BV is a limited liability company registered in the trade register
>> of the Chamber of Commerce as TNO DIANA BV with registered number 27252655.
>> ____________________________________________________________
>> This e-mail and its contents are subject to the DISCLAIMER at
>> http://tnodiana.com/content/Disclaimer
>> ____________________________________________________________
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>

____________________________________________________________
TNO DIANA BV is a limited liability company registered in the trade register of the Chamber of Commerce as TNO DIANA BV with registered number 27252655.
____________________________________________________________
This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer
____________________________________________________________



More information about the vtk-developers mailing list