CGAL users discussion list

[Camille Wormser <>]

> Recently I had to write some code to find the intersection of a
> Triangle_3 and Segment_3. I noticed that I could do a
> CGAL::do_intersect() [1] of these to find *if* there is any
> intersection. But, I *cannot* do a CGAL::intersection() [2] of these
> objects to obtain the intersection object. What is the reason for this
> API design?
>
> Currently, I get around this by:
> (1) Getting the Plane_3 of the triangle using  
> Triangle_3::supporting_plane()
> (2) CGAL::intersection of the Plane_3 and the Segment_3 to get the
> intersection object.
> (3) Checking if the intersection CGALObject thus obtained lies on the
> Triangle_3.
>
> Is there a better way to do this?

A better way would be to use the do_intersect predicate, because it is  
exact and still efficient, as soon as you are using an  
Exact_predicate_inexact_constructions_kernel. This would mean

1) checking whether the Triangle_3 and the Segment_3 do intersect or  
not with CGAL::do_intersect

2) if they do intersect, using CGAL::intersection for the  
supporting_plane of the triangle and the segment. Then you have to  
deal with the various possible results (in particular with an inexact  
constructions kernel): if it is a point, you are done. If it is empty  
(this is possible if the constructions are inexact, this is not a  
bug), you face a robustness issue that you will have to solve in the  
most relevant way for your application. If it is the whole segment,  
you have to compute the intersection of a triangle and a segment in a  
2d plane in 3-space. You can then use CGAL::intersection between  
Triangle_2 and Segment_2, after projection.

For (2), either you will use an exact constructions (but slow) kernel,  
and the code will be simple for you to write anyway, or you will use  
an inexact constructions (but fast) kernel, and you will have to  
choose how to deal with the unavoidable robustness issues.

I hope this makes clear why it is much more important to provide the  
do_intersect predicate than the intersection construction for these  
data types.
--
Camille