[vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter

Fri Apr 17 15:21:24 EDT 2015

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
> ____________________________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150417/41314f1b/attachment-0001.html>