<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Will,<br>
<br>
I don't think the picture conforms to the parametric coordinates...<br>
<br>
static double vtkWedgeCellPCoords[18] = {0.0,0.0,0.0, 1.0,0.0,0.0,
0.0,1.0,0.0,<br>
0.0,0.0,1.0, 1.0,0.0,1.0, 0.0,1.0,1.0};<br>
<br>
Vectors joining PCoords 0-1, 0-2, 0-3 form a RH set and in this
sense it is consistent with the tetrahedron.<br>
<br>
The problem seems to be with the ordering given internally to the
nodes on each face, rather than the cell ordering.<br>
<br>
John.<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 20/04/2015 17:00, Will Schroeder
wrote:<br>
</div>
<blockquote
cite="mid:CAEiDrtXi6AaHEBiG11dOcDTBy_pxzpxtzdEfLxpv0j4PagetGQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Andreas-
<div><br>
</div>
<div>Interesting discussion, I'm sorry that I'm late to the
party. Here are some random items:</div>
<div><br>
</div>
<div>1. This document is worth viewing if you have not seen it
already (on page 9):</div>
<div><a moz-do-not-send="true"
href="http://ins.uni-bonn.de/teaching/alumni/bebendorf/Praktikum_SS12/vtk_file_formats.pdf">http://ins.uni-bonn.de/teaching/alumni/bebendorf/Praktikum_SS12/vtk_file_formats.pdf</a> </div>
<div>has a pictorial representation of the point ordering (the <a
moz-do-not-send="true" href="http://vtk.org">vtk.org</a>
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.</div>
<div><br>
</div>
<div>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 <span style="font-size:19.2000007629395px">vtkUnstructuredGridGeometryFil</span><span
style="font-size:19.2000007629395px">ter 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.</span><br>
</div>
<div><span style="font-size:19.2000007629395px"><br>
</span></div>
<div><span style="font-size:19.2000007629395px">W</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Apr 20, 2015 at 6:49 AM,
Andreas Buykx <span dir="ltr"><<a moz-do-not-send="true"
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 link="blue" vlink="purple" lang="NL">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Hi,</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Good point about IntersectWithLine.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Note as well that the documentation of
the vtkWedge states that the points are arranged
such that bottom triangle normal points
<i>away</i> from the other triangle face, so
outward. This in contrast to the vtkHexahedron where
the bottom quadrilateral points
<i>towards</i> the other face, so inward. I suppose
the definition of the cell will not be changed, that
would have a significant impact for sure.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">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. </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">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?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Kind regards,</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Andreas</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US"> Berk Geveci [mailto:<a
moz-do-not-send="true"
href="mailto:berk.geveci@kitware.com"
target="_blank">berk.geveci@kitware.com</a>]
<br>
<b>Sent:</b> vrijdag 17 april 2015 21:21<br>
<b>To:</b> Andreas Buykx; VTK Developers</span></p>
<div>
<div class="h5"><br>
<b>Subject:</b> Re: [vtk-developers] vtkWedge face
node ordering and vtkUnstructuredGridGeometryFilter</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Dear Andreas,</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Best,</p>
</div>
<div>
<p class="MsoNormal">-berk</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Wed, Apr 8, 2015 at 4:50
AM, Andreas Buykx <<a
moz-do-not-send="true"
href="mailto:A.Buykx@tnodiana.com"
target="_blank">A.Buykx@tnodiana.com</a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi
Berk,</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">I just pushed my work. I
think it would be good to add the python
script as well somewhere?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a
moz-do-not-send="true"
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></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Happy holidays,</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US">Andreas</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"
lang="EN-US"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US"> Berk Geveci [mailto:<a
moz-do-not-send="true"
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>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: [vtk-developers]
vtkWedge face node ordering and
vtkUnstructuredGridGeometryFilter</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Hi Andreas,</p>
<div>
<p class="MsoNormal"> </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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Best,</p>
</div>
<div>
<p class="MsoNormal">-berk</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Fri, Apr 3,
2015 at 8:06 AM, Andreas Buykx
<<a moz-do-not-send="true"
href="mailto:A.Buykx@tnodiana.com"
target="_blank">A.Buykx@tnodiana.com</a>>
wrote:</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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:vtk-developers@vtk.org"
target="_blank">vtk-developers@vtk.org</a><br>
Subject: Re: [vtk-developers]
vtkWedge face node ordering and
vtkUnstructuredGridGeometryFilter</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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="http://tnodiana.com/content/Disclaimer"
target="_blank">http://tnodiana.com/content/Disclaimer</a><br>
>>
____________________________________________________________<br>
>><br>
>>
_______________________________________________<br>
>> Powered by <a
moz-do-not-send="true"
href="http://www.kitware.com"
target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware
open-source projects at<br>
>> <a
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="http://www.kitware.com"
target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware
open-source projects at <a
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://tnodiana.com/content/Disclaimer" target="_blank">
http://tnodiana.com/content/Disclaimer</a><br>
____________________________________________________________</p>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span
style="font-family:"Courier
New"">____________________________________________________________<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
moz-do-not-send="true"
href="http://tnodiana.com/content/Disclaimer"
target="_blank">
http://tnodiana.com/content/Disclaimer</a><br>
____________________________________________________________</span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </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 moz-do-not-send="true"
href="http://tnodiana.com/content/Disclaimer"
target="_blank">http://tnodiana.com/content/Disclaimer</a><br>
____________________________________________________________</font></div>
</div>
</div>
<br>
_______________________________________________<br>
Powered by <a moz-do-not-send="true"
href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://public.kitware.com/mailman/listinfo/vtk-developers"
target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">William J. Schroeder, PhD<br>
Kitware, Inc.<br>
28 Corporate Drive<br>
Clifton Park, NY 12065<br>
<a moz-do-not-send="true"
href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br>
<a moz-do-not-send="true" href="http://www.kitware.com"
target="_blank">http://www.kitware.com</a><br>
(518) 881-4902</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Powered by <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>
Visit other Kitware open-source projects at <a class="moz-txt-link-freetext" href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a>
Search the list archives at: <a class="moz-txt-link-freetext" href="http://markmail.org/search/?q=vtk-developers">http://markmail.org/search/?q=vtk-developers</a>
Follow this link to subscribe/unsubscribe:
<a class="moz-txt-link-freetext" href="http://public.kitware.com/mailman/listinfo/vtk-developers">http://public.kitware.com/mailman/listinfo/vtk-developers</a>
</pre>
</blockquote>
<br>
</body>
</html>