*identity test of span must be done using directions
*add a test for identical but opposite spans
*add missing make_exact calls
*special case of has_same_support for vertical bezier
*special case of _is_in_range for vertical bezier
*add a do-while loop to increase precision in _exact_vertical_position
Fuzzy_sphere_3<Search_traits> tried to use Point_d::dimension(), instead of
using Search_traits::Construct_cartesian_const_iterator_d. With a custom
Point_d, there was a compilation error.
| ------------------------------------------------------------------------
| r56226 | avaxman | 2010-05-13 22:16:14 +0200 (Thu, 13 May 2010) | 1 line
| Changed paths:
| A /trunk/Subdivision_oracle
|
| Subdivision for Oracle Surfaces GSoC Project - Amir Vaxman
| ------------------------------------------------------------------------
The real location of the code is:
/branches/experimental-packages/Subdivision_surface_oracle
If one wants to use Mesh_2 with Triangulation_2_projection_traits_3 (a
projection traits constructed with a normal vector), one cannot use a
default constructed geom traits, but only one passed on argument. Then the
criteria class needs to be constructed with tr.geom_traits() as argument.
Before this patch, Construct_initial_points did not try to intersect with
the bounding polyhedron, but only with the other polyhedra. That can lead
to a crash if the given polyhedra are a bounding one, and a second
polyhedron that is coplanar. Then the initial points are *all* coplanar,
and then tr.dimension()==2 and an assertion is triggered.
Now Construct_initial_points uses construct_intersection_object(), and the
later tries to intersect with all polyhedra, including the bounding one.
Changed the calls mpfr_get_z_exp -> mpfr_get_z_2exp for MPFR>2 (the old
function name may be deprecated in future versions).
Added comments in the Gmpfr code about Gmpfr destructors.
Updated my mail address in source files.
On Windows, with MSVC, std::fabs is an intrinsic function with /Oi (implied
with /O1, /O2, and so on) *if* /fp:strict is not used. We should reevaluate
the need to use /fp:strict (and maybe use /fp:precise, the default,
combined with #pragma fenv_access).
First step: bench! This macro will help.
*fix a bug in resultant computation
*a missing originator when using split with an endpoint of a bezier.
this happen for example when computing the arrangement of a vertical bezier
and another one having its start point on the vertical one
*fix bug in skewbbox intersection in the case of a vertical bezier