<!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>
<DIV><FONT size=2 face=Arial>Hi Philippe,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>From an engineering standpoint, angles for arcs are 
very rarely quoted. Another alternative is to fix the current implementation so 
that Point2 does not have to lie on the arc and is used only for the arc plane 
and angle and note the limitation about collinear Point1 & Point2. Then put 
the new API in vtkArcSource2. But you have probably considered 
this.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>The API change will not affect me but thought 
it courteous to respond to your invitation for comments.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>John.</FONT></DIV></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=jcplatt@dsl.pipex.com 
  href="mailto:jcplatt@dsl.pipex.com">John Platt</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, December 01, 2011 8:03 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [vtk-developers] Ill-posed 
  problem in vtkArcSource</DIV>
  <DIV><BR></DIV>Hello John<BR><BR>Thanks for the reply. In the current 
  implementation, Point2 is also used to specify the angle, as you described (in 
  addition to specifying a plane). I think this is a problem because it lets the 
  user specify an Point2 that does not belong to the arc, and the output will in 
  this case not be an arc. <BR><BR>The problem that I see with requiring the 
  normal only in the degenerate cases is that the user might not know this; or, 
  a program using the arc source might be asked to work in all cases, including 
  flat and null angles, which means that one would either have to rewrite the 
  code to use the new interface (thus making useless anyway the old API), or, 
  test thevalue of the angle to use the new API in some cases only, which would 
  create unnecessary code complexity.<BR><BR>I think that we are going to go 
  ahead with a new, consistent and generic API. Will some of you own code be 
  potentially affected by this?<BR><BR>Thank you<BR>Philippe<BR> <BR>
  <DIV class=gmail_quote>On Wed, Nov 30, 2011 at 1:08 AM, John Platt <SPAN 
  dir=ltr><<A href="mailto:jcplatt@dsl.pipex.com" 
  target=_blank>jcplatt@dsl.pipex.com</A>></SPAN> wrote:<BR>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
  class=gmail_quote><U></U>
    <DIV 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>
      <DIV></DIV>
      <DIV>
      <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
      <DIV style="FONT: 10pt arial; BACKGROUND: #e4e4e4"><B>From:</B> <A 
      title=philippe.pebay@kitware.com href="mailto:philippe.pebay@kitware.com" 
      target=_blank>Philippe Pebay</A> </DIV>
      <DIV style="FONT: 10pt arial"><B>To:</B> <A title=vtk-developers@vtk.org 
      href="mailto:vtk-developers@vtk.org" target=_blank>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></DIV></DIV>
      <P></P>
      <HR>

      <P></P>_______________________________________________<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>Follow 
      this link to subscribe/unsubscribe:<BR><A 
      href="http://www.vtk.org/mailman/listinfo/vtk-developers" 
      target=_blank>http://www.vtk.org/mailman/listinfo/vtk-developers</A><BR><BR>
      <P></P></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV><BR><BR clear=all><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></BLOCKQUOTE></BODY></HTML>