[vtk-developers] Ill-posed problem in vtkArcSource

[John Platt]

Hi Philippe,

>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.

The API change will not affect me but thought it courteous to respond to your invitation for comments.

John.
  ----- Original Message ----- 
  From: Philippe Pebay 
  To: John Platt 
  Sent: Thursday, December 01, 2011 8:03 AM
  Subject: Re: [vtk-developers] Ill-posed problem in vtkArcSource


  Hello John

  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. 

  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.

  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?

  Thank you
  Philippe
   

  On Wed, Nov 30, 2011 at 1:08 AM, John Platt <jcplatt at dsl.pipex.com> wrote:

    Hi Philippe,

    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.

    John.
      ----- Original Message ----- 
      From: Philippe Pebay 
      To: VTK Developers 
      Sent: Tuesday, November 29, 2011 8:58 PM
      Subject: [vtk-developers] Ill-posed problem in vtkArcSource


      Hello all,

      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.

      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:

        double v1[3] = { this->Point1[0] - this->Center[0],
                         this->Point1[1] - this->Center[1],
                         this->Point1[2] - this->Center[2] };
        double v2[3] = { this->Point2[0] - this->Center[0],
                         this->Point2[1] - this->Center[1],
                         this->Point2[2] - this->Center[2] };
        double normal[3], perpendicular[3];
        vtkMath::Cross( v1, v2, normal );
        vtkMath::Cross( normal, v1, perpendicular );
        vtkMath::Normalize( perpendicular );

      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).

      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.

      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).

      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 :
      - a center [unchanged from current API]
      - a normal (providing the orientation for the rotation as well as the plane)
      - an angle
      - an angular resolution [unchanged from current API]
      With those in hand, the gist of the algorithm creating the arc itself would remain unchanged. This new API would solve both problems. 

      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.

      I reported an issue in the bug tracker, but thought that an e-mail to the list would probably elicit more discussion.

      Looking forward to your comments,
      Thank you,
      Philippe


      -- 
      Philippe Pébay
      Directeur de la Visualisation et du Calcul Haute Performance
      Kitware SAS
      20 rue de la Villette
      69328 Lyon cedex 03, France
      +33 (0)4.26.68.50.03
      http://www.kitware.fr



--------------------------------------------------------------------------


      _______________________________________________
      Powered by www.kitware.com

      Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

      Follow this link to subscribe/unsubscribe:
      http://www.vtk.org/mailman/listinfo/vtk-developers






  -- 
  Philippe Pébay
  Directeur de la Visualisation et du Calcul Haute Performance
  Kitware SAS
  20 rue de la Villette
  69328 Lyon cedex 03, France
  +33 (0)4.26.68.50.03
  http://www.kitware.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20111201/2359a538/attachment.html>