[vtk-developers] Ill-posed problem in vtkArcSource

Philippe Pebay philippe.pebay at kitware.com
Tue Nov 29 15:58:50 EST 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20111129/e9e1c953/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Incorrect180DegreesArc.png
Type: image/png
Size: 18991 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20111129/e9e1c953/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InconsistentArcSpec.png
Type: image/png
Size: 21904 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20111129/e9e1c953/attachment-0003.png>


More information about the vtk-developers mailing list