<div dir="ltr">Dear Andreas,<div><br></div><div>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?</div><div><br></div><div>Best,</div><div>-berk</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 4:50 AM, Andreas Buykx <span dir="ltr"><<a href="mailto:A.Buykx@tnodiana.com" target="_blank">A.Buykx@tnodiana.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="NL" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Berk,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I just pushed my work. I think it would be good to add the python script as well somewhere?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="https://gitlab.kitware.com/bxa/vtk/tree/wedge-face-points" target="_blank"><span lang="EN-US">https://gitlab.kitware.com/bxa/vtk/tree/wedge-face-points</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Happy holidays,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Andreas<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Berk Geveci [mailto:<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>]
<br>
<b>Sent:</b> dinsdag 7 april 2015 18:49<br>
<b>To:</b> Andreas Buykx</span></p><div><div class="h5"><br>
<b>Subject:</b> Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter<u></u><u></u></div></div><p></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi Andreas,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Best,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">-berk<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Fri, Apr 3, 2015 at 8:06 AM, Andreas Buykx <<a href="mailto:A.Buykx@tnodiana.com" target="_blank">A.Buykx@tnodiana.com</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">Hi,<br>
<br>
All non-linear wedges have the same ordering of face points, causing their normal to point inward.<br>
<br>
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?<br>
<br>
>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 ;-).<br>
<br>
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).<br>
<br>
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.<br>
<br>
How do we proceed?<br>
<br>
Kind regards,<br>
Andreas<br>
<br>
________________________________________<br>
From: John Platt [<a href="mailto:jcplatt@dsl.pipex.com" target="_blank">jcplatt@dsl.pipex.com</a>]<br>
Sent: Wednesday, April 01, 2015 10:09 PM<br>
To: Berk Geveci; Andreas Buykx<br>
Cc: <a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a><br>
Subject: Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Hi,<br>
<br>
I think this is also a problem for vtkDataSetSurfaceFilter when mixing<br>
quadratic hex's & wedges. If the actor opacity is reduced, the internal<br>
faces between the hex's & wedges are visible.<br>
<br>
This can be fixed by turning the wedge inside-out i.e. swapping points 1<br>
& 2 and 4 & 5. The FE system I work with allows both right and left<br>
handed elements so the topology of each element must be checked and<br>
inverted if necessary.<br>
<br>
I agree that the order of the nodes in the face arrays should be changed<br>
to be consistent with the other cells. I suspect this would largely go<br>
unnoticed given the time this inconsistency has been present and the<br>
number of reports on the behaviour.<br>
<br>
Thanks,<br>
<br>
John.<br>
<br>
<br>
<br>
On 01/04/2015 16:42, Berk Geveci wrote:<br>
> Hi Andreas,<br>
><br>
> Changing the ordering of vtkWedge would be a very large undertaking<br>
> given that there is years of documentation, file formats (in VTK and<br>
> 3rd party), code etc. that depend on a certain ordering. One less<br>
> intrusive way would be to change any vtkWedge methods that returns<br>
> faces to return them in a different order. I suspect this option is<br>
> doable but I'd like to hear from the community. The least intrusive<br>
> options is to fix the few filters that have this issue but I feel like<br>
> it is a band-aid.<br>
><br>
> Best,<br>
> -berk<br>
><br>
> On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx <<a href="mailto:A.Buykx@tnodiana.com" target="_blank">A.Buykx@tnodiana.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>><br>
>><br>
>> To detect if coinciding faces of neighbouring 3D cells are connected,<br>
>> vtkUnstructuredGridGeometryFilter walks the points of these faces in<br>
>> opposite directions and expects the point ids to match. This fails for<br>
>> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by the<br>
>> python script I attach. The root cause is that the vtkWedge::GetFaceArray<br>
>> and vtkWedge::GetFace return the face points in an ordering that makes the<br>
>> face normal point into the 3D cell instead of out of the  3D cell, like all<br>
>> other 3D cells do. The two other algorithms that generate surface cells<br>
>> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don't suffer from this<br>
>> ordering because the former checks point ordering but explicitly allows both<br>
>> loop directions, and the latter only takes cell connectivity into account<br>
>> without checking point-ordering at all.<br>
>><br>
>><br>
>><br>
>> I don't know what the reason is to have a different face-point ordering for<br>
>> the vtkWedge, but one of the other consequences is that the outer surface<br>
>> will have inconsistent cell normals as can easily be seen when loading the<br>
>> xml files produced by the tests in paraview, and showing the cell normals.<br>
>> So I would prefer to change the face-point ordering in vtkWedge. If that is<br>
>> not possible for some reason then I propose to make/update the case-blocks<br>
>> in the surface filters cell-type switches to re-order the face-points for<br>
>> the wedge faces. As long as this is not dealt with our FEA models will show<br>
>> edges where they should not be so I will have to solve this issue one way or<br>
>> another, and I'd like to contribute it to VTK as well.<br>
>><br>
>><br>
>><br>
>> Shall I make a mantis issue for this? Who can help me with the git/gerrit<br>
>> stuff?<br>
>><br>
>><br>
>><br>
>> Thanks a lot,<br>
>><br>
>> Andreas Buykx<br>
>><br>
>> ____________________________________________________________<br>
>> TNO DIANA BV is a limited liability company registered in the trade register<br>
>> of the Chamber of Commerce as TNO DIANA BV with registered number 27252655.<br>
>> ____________________________________________________________<br>
>> This e-mail and its contents are subject to the DISCLAIMER at<br>
>> <a href="http://tnodiana.com/content/Disclaimer" target="_blank">http://tnodiana.com/content/Disclaimer</a><br>
>> ____________________________________________________________<br>
>><br>
>> _______________________________________________<br>
>> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware open-source projects at<br>
>> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>><br>
>> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" target="_blank">
http://markmail.org/search/?q=vtk-developers</a><br>
>><br>
>> Follow this link to subscribe/unsubscribe:<br>
>> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">
http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>><br>
>><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">
http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" target="_blank">
http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">
http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
><br>
<br>
____________________________________________________________<br>
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.<br>
____________________________________________________________<br>
This e-mail and its contents are subject to the DISCLAIMER at <a href="http://tnodiana.com/content/Disclaimer" target="_blank">
http://tnodiana.com/content/Disclaimer</a><br>
____________________________________________________________<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div><div><div class="h5">
<font face="monospace">____________________________________________________________<br>
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.<br>
____________________________________________________________<br>
This e-mail and its contents are subject to the DISCLAIMER at <a href="http://tnodiana.com/content/Disclaimer" target="_blank">http://tnodiana.com/content/Disclaimer</a><br>
____________________________________________________________</font></div></div></div>

</blockquote></div><br></div>