[vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter

Mon Apr 20 06:49:16 EDT 2015

Hi,

Good point about IntersectWithLine.
I added a IntersectWithLine test to wedge_test.py, and intersect with a line parallel to the wedge’s axis both from top to bottom and from bottom to top. I apply the same test to a hexahedron.

Apparently, in VTK6.2.0, the top and bottom parameterized coordinate are returned for the wedge’s triangles with face-normal pointing inward, but for the hexahedron’s quadrilaterals with a face-normal pointing outward. This is consistent with the wedge being defined inside-out. Should this behavior be changed as well? If not there is an inconsistency between face orientation and behavior of IntersectWithLine, if it is changed, many calling filters may yield different results.

Note as well that the documentation of the vtkWedge states that the points are arranged such that bottom triangle normal points away from the other triangle face, so outward. This in contrast to the vtkHexahedron where the bottom quadrilateral points towards the other face, so inward.  I suppose the definition of the cell will not be changed, that would have a significant impact for sure.

However, I don’t think though that the cell point ordering is supposed to be related to the parameterization of the intersection of the faces:  given the cell point ordering the two opposite faces of wedge and hexahedron have normals that point in the same absolute direction, so one face normal points inward and one face normal points outward. The IntersectWithLine implementations return parameterizations that orient the normals either both inward or both outward.

So, I’m not sure as to what should be done. I think with my change the face normals are oriented outward, and the intersection point parameterization should be consistent with that.  What are your views?

Kind regards,
Andreas

From: Berk Geveci [mailto:berk.geveci at kitware.com]
Sent: vrijdag 17 april 2015 21:21
To: Andreas Buykx; VTK Developers
Subject: Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter

Dear Andreas,

I took a look at your branch. At an initial glance, things look good. I will dig deeper and also ask for some help in the near future. I have one question: I noticed that vtkWedge::IntersectWithLine() uses face information. Did you verify that it still works?

Best,
-berk

On Wed, Apr 8, 2015 at 4:50 AM, Andreas Buykx <A.Buykx at tnodiana.com<mailto:A.Buykx at tnodiana.com>> wrote:
Hi Berk,

I just pushed my work. I think it would be good to add the python script as well somewhere?

https://gitlab.kitware.com/bxa/vtk/tree/wedge-face-points

Happy holidays,
Andreas

From: Berk Geveci [mailto:berk.geveci at kitware.com<mailto:berk.geveci at kitware.com>]
Sent: dinsdag 7 april 2015 18:49
To: Andreas Buykx

Subject: Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter

Hi Andreas,

Can you please point me to your branch? I am on vacation for the rest of the week so you may not hear from me for a few days.

Best,
-berk

On Fri, Apr 3, 2015 at 8:06 AM, Andreas Buykx <A.Buykx at tnodiana.com<mailto:A.Buykx at tnodiana.com>> wrote:
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<mailto:jcplatt at dsl.pipex.com>]
Sent: Wednesday, April 01, 2015 10:09 PM
To: Berk Geveci; Andreas Buykx
Cc: vtk-developers at vtk.org<mailto: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<mailto: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<http://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<http://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
____________________________________________________________

____________________________________________________________
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
____________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150420/0bbd6ee3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wedge_test.py
Type: application/octet-stream
Size: 8034 bytes
Desc: wedge_test.py
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150420/0bbd6ee3/attachment-0001.obj>