Yes, that surely explains the behaviour Nicolas is getting. The way to look at the initialization for the contour widget is that its initializing the control points. The input is sort of assumed to a vtkPolyData containing a single vtkPolyline cell. (in which case, the points would have been in order). <br>
<br><br><br><div class="gmail_quote">On Fri, May 7, 2010 at 11:35 AM, Arnaud GELAS <span dir="ltr"><<a href="mailto:arnaud_gelas@hms.harvard.edu">arnaud_gelas@hms.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi guys,<br>
<br>
I was looking at the code of vtkContourWidget::Initialize and thus vtkContourRepresentation::Initialize method, and it seems that the initialization does not take into account the connectivity information stored into the input polydata.<br>

For instance, vtkContourRepresentation appends to the node container points from the input polydata in the same order of the points container.<br>
<br>
In vtkContourRepresentation.cxx<br>
<br>
1217   for ( vtkIdType i=0; i < nPoints; i++ )<br>
1218     {<br>
1219     double *p = points->GetPoint( i );<br>
1220     this->AddNodeAtWorldPosition( p, worldOrient );<br>
1221     }<br>
<br>
I guess such a behavior may explain why Nicolas gets such results when passing a contour resulting from a marching squares to a contour widget.<br>
<br>
<a href="http://www.vtk.org/pipermail/vtkusers/2010-May/108826.html" target="_blank">http://www.vtk.org/pipermail/vtkusers/2010-May/108826.html</a><br>
<br>
I just wonder if it is supposed to be the normal behavior?<br>
and if not what would be the best way to fix it?<br>
assuming the polydata contains lines? assuming the input comes from a vtkStripper?<br>
<br>
Thanks,<br>
Best,<br><font color="#888888">
Arnaud<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>