<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19154">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>Hi Philippe,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I presume Point1 (projected onto the arc
plane) is retained to specify the radius and start of the arc. Point2 could
be used instead of the angle to determine the turn of the arc (not radius to
avoid the inconsistency you mentioned). You could then say that the normal was
only required when Point1 & Point2 are collinear and defaults to (0,0,1).
Just a thought.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>John.</FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B>
<A title=philippe.pebay@kitware.com
href="mailto:philippe.pebay@kitware.com">Philippe Pebay</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=vtk-developers@vtk.org
href="mailto:vtk-developers@vtk.org">VTK Developers</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, November 29, 2011 8:58
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> [vtk-developers] Ill-posed
problem in vtkArcSource</DIV>
<DIV><BR></DIV>Hello all,<BR><BR>A couple of weeks ago, I noticed that
vtkArcSource was yielding incorrect outputs for flat [mod pi] angles, i.e.,
when the Center, Point1 and Point2 point instance variables were
aligned.<BR><BR>I thought it was a simple bug which would be readily fixed. I
finally found time to return to it today, only to notice that the cause of the
problem is to be found in the following lines:<BR><BR> double v1[3] = {
this->Point1[0] -
this->Center[0],<BR>
this->Point1[1] -
this->Center[1],<BR>
this->Point1[2] - this->Center[2] };<BR> double v2[3] = {
this->Point2[0] -
this->Center[0],<BR>
this->Point2[1] -
this->Center[1],<BR>
this->Point2[2] - this->Center[2] };<BR> double normal[3],
perpendicular[3];<BR> vtkMath::Cross( v1, v2, normal );<BR>
vtkMath::Cross( normal, v1, perpendicular );<BR> vtkMath::Normalize(
perpendicular );<BR><BR>Specifically, the source of the problem is the
utilization of the cross (vector) product to find the normal between v1 and
v2, the coordinate vectors of Point1 and Point2 with respect to the center of
the arc: when they are aligned with the centers, v1 and v2 become co-linear,
and as a result the cross product vanishes within machine precision, hence
causing the rest of the algorithm to fall apart (cf. 1st attached
image).<BR><BR>As I was thinking of a fix (by checking for nullity of the
cross product within some tolerance, and then creating an ad-hoc normal
vector), I realized that in this particular case, the problem was in fact
ill-posed: indeed, if Center, Point1, and Point2 are aligned, with the two
latter points being equidistant from the former, then there is an infinity of
arcs satisfying the specification. In other words, the current API of
vtkArcSource does not allow for a unique specification of flat [mod pi]
angles, because in this case there is not one particular arc to be chosen and
drawn. There is, therefore, no possible fix with the current API.<BR><BR>In
addition to this issue, the current API poses the (already known) problem that
it is possible to specify an over-constrained and inconsistent input, when
Point1 and Point2 are not equidistant from the center, causing the algorithm
to draw an arc attached to a segment reaching out to the former point (cf. 2nd
attached image).<BR><BR>At this point, I would therefore suggest that the API
be changed to allow for another, consistent and generic specification of an
arc: namely, it would have :<BR>- a center [unchanged from current API]<BR>- a
normal (providing the orientation for the rotation as well as the plane)<BR>-
an angle<BR>- an angular resolution [unchanged from current API]<BR>With those
in hand, the gist of the algorithm creating the arc itself would remain
unchanged. This new API would solve both problems. <BR
clear=all><BR>Currently, only a couple of classes in VTK proper appear to be
using vtkArcSource. It would thus be easy to upgrade VTK to the new arc
source. For other applications we could leave the current instance variables
available until we decide to deprecate the current approach altogether. As the
arc-drawing algorithm would remain essentially unchanged, a test checking
which of the two arc specifications is to be used (the older one, for
backwards compatibility, being the default for the time being) would suffice
to make approaches cohabit for a while.<BR><BR>I reported an issue in the bug
tracker, but thought that an e-mail to the list would probably elicit more
discussion.<BR><BR>Looking forward to your comments,<BR>Thank
you,<BR>Philippe<BR><BR><BR>-- <BR><FONT color=#888888>Philippe
Pébay<BR>Directeur de la Visualisation et du Calcul Haute
Performance<BR>Kitware SAS<BR>20 rue de la Villette<BR>69328 Lyon cedex 03,
France<BR><A value="+33426685003">+33 (0)4.26.68.50.03</A><BR><A
href="http://www.kitware.fr/"
target=_blank>http://www.kitware.fr</A></FONT><BR>
<P>
<HR>
<P></P>_______________________________________________<BR>Powered by
www.kitware.com<BR><BR>Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html<BR><BR>Follow this link to
subscribe/unsubscribe:<BR>http://www.vtk.org/mailman/listinfo/vtk-developers<BR><BR></BLOCKQUOTE></BODY></HTML>