[vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter

Mon Apr 20 12:00:04 EDT 2015

Hi Andreas-

Interesting discussion, I'm sorry that I'm late to the party. Here are some
random items:

1. This document is worth viewing if you have not seen it already (on page
9):
http://ins.uni-bonn.de/teaching/alumni/bebendorf/Praktikum_SS12/vtk_file_formats.pdf

has a pictorial representation of the point ordering (the vtk.org link to
this file is broken due to our recent rework of the VTK web pages; I have
informed our web people). Note that the vtkWedge is ordered inconsistently
with all other cells as you have pointed out. I have no idea why: whether
it was another cook in the kitchen or whether a brain was not functioning
properly that day.

2. As Berk pointed out, changing the point ordering at this late date is
problematic, mainly because lots of people have written files assuming this
ordering. My main concern is to make sure that once the data is ingested
into VTK from that point on the computations are consistent. This includes
filters like vtkUnstructuredGridGeometryFilter and also all internal
methods for parameterization and topological access. So let's identify the
inconsistencies (I think you've already done most of the work) and make
sure that everything is consistent once the data is read into VTK.

W

On Mon, Apr 20, 2015 at 6:49 AM, Andreas Buykx <A.Buykx at tnodiana.com> wrote:

>  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>
> 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]
> *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>
> 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]
> 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
> ____________________________________________________________
>
>
>
> ____________________________________________________________
> 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
> ____________________________________________________________
>
> _______________________________________________
> 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
>
>
>

-- 
William J. Schroeder, PhD
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150420/04e06bb9/attachment-0001.html>