CGAL users discussion list

["Sebastien Loriot (GeometryFactory)" <>]

Check this FAQ entry:
http://www.cgal.org/FAQ.html#inexact_NT

If you use Exact_predicates_exact_constructions_kernel.h this should be OK.

Even if it's not documented and not officially supported, I suggest you 
to have a look at the file CGAL/intersection_of_Polyhedra_3.h

where the following function is defined:

template <typename Polyhedron, typename OutputIterator>
OutputIterator
intersection_Polyhedron_3_Polyhedron_3(const Polyhedron& P, const 
Polyhedron& Q, OutputIterator out)

where OutputIterator accepts std::vector<typename Kernel::Point_3> 
objects (to represent a polyline).

A plane can always be represented by a triangulated quad.

Sebastien.


On 02/08/2013 12:31 AM, Jeffrey Bush wrote:
> Hi,
>
> I am using AABB_tree to determine intersections between a plane (call it
> "h") and a polyhedron, resulting in a vector of segments ("segs").
> However the following test fails:
>
>     h.has_on(*segs.begin())
>
>
> This shouldn't be. However doing research I realized the result may be
> because of using Cartesian instead of
> Exact_predicates_inexact_constructions_kernel, so I switched to that.
> But still the same problem!
>
> Running the debugger I get to this function:
>
>    inline
>    Uncertain<Sign>
>    sign (const  Interval_nt<Protected>  &  d)
>    {
>      if  (d.inf()>  0.0)return  POSITIVE;
>      if  (d.sup()<  0.0)return  NEGATIVE;
>      if  (d.inf() == d.sup())return  ZERO;
>      return  Uncertain<Sign>::indeterminate();
>    }
>
> With the following value for d:
>
> d = {
>    _inf=5.6843418860808015e-014,
>    _sup=5.6843418860808015e-014,
>    tester={...}
> }
>
> It seems as though the d.inf() == d.sup() check should be first? It
> seems that if sup <= inf and inf > 0 or sup < 0, then the d.inf() ==
> d.sup() can only be 0 == 0... (but I guess sup > inf - I don't
> understand exactly what this is all about).
>
> Just for scale, my points have values on the order of 2500 and the plane
> is <0,0,1> -300.
>
> If this is right (and I could easily be, I don't know too much about
> double-precision mathematical testing), then what am I doing wrong? My
> meshes are LARGE so I don't want to use the infinite-precision numbers.
>
> Thanks!
> Jeff