[vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter
John Platt
jcplatt at dsl.pipex.com
Mon Apr 20 17:20:37 EDT 2015
Hi Will,
I don't think the picture conforms to the parametric coordinates...
static double vtkWedgeCellPCoords[18] = {0.0,0.0,0.0, 1.0,0.0,0.0,
0.0,1.0,0.0,
0.0,0.0,1.0, 1.0,0.0,1.0, 0.0,1.0,1.0};
Vectors joining PCoords 0-1, 0-2, 0-3 form a RH set and in this sense it
is consistent with the tetrahedron.
The problem seems to be with the ordering given internally to the nodes
on each face, rather than the cell ordering.
John.
On 20/04/2015 17:00, Will Schroeder wrote:
> 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
> <http://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
> <mailto: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
> <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
> ____________________________________________________________
>
> ____________________________________________________________
> 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
>
>
>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com <mailto:will.schroeder at kitware.com>
> http://www.kitware.com
> (518) 881-4902
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150420/88dfefd5/attachment-0001.html>
More information about the vtk-developers
mailing list