-- canonical_dual() is what the old dual() function was: returns the
representation of the dual of the cell handle that is in the domain
-- dual() returns the 'true' dual of the cell handle, which might be out of
the canonical domain.
The point is that P3M3 must return the 'true' dual to have no issue with the
conflict assertions of Mesh_3, and not a canonicalized dual !
This is a way to handle points that are epsilon-close to the boundary yet still
outside. This might create numerical issue such that the point + any offset
does not fall into the domain (due to -epsilon + 1 ~= 1)
The numerical issue is detected when the offset is computed and we snap the
point to the domain.
This is done for P3M3 only (not P3T3: people should give proper input points!)
The purpose of that class is somewhat similar to Robust_weighed_circum...etc.:
it aims to provide robust circumcenter computations.
This is the parallel version that switches to exact if the circumcenter is
not in the (smallest) power sphere of the points.
The accuracy issue comes from the use of construct_point_3 with offsets.
Consequently, this class only overrides the versions with offsets.
The other robust class should be used for non-offset versions.
Commit f554c062e39978fd8c0f15ba6a6d90597b36d768 fixed a lot of stuff
but point() functions were still a bit messy.
Now, ALL `point()` functions return a canonical point. If one wants to
get the "real" point in the complete space, one should use v->point()
point() must be the canonical point and not the real point since we
will pass P3T3 to other packages (Mesh_3/Alpha_shapes_3) that will
use tr.point(v) and expect the canonical point.
Might be worth to introduce a function "real_point()" to return v->point()
Commit f554c062e39978fd8c0f15ba6a6d90597b36d768 fixed a lot of stuff
but point() functions were still a bit messy.
Now, ALL `point()` functions return a canonical point. If one wants to
get the "real" point in the complete space, one should use v->point()
point() must be the canonical point and not the real point since we
will pass P3T3 to other packages (Mesh_3/Alpha_shapes_3) that will
use tr.point(v) and expect the canonical point.
Might be worth to introduce a function "real_point()" to return v->point()
This reverts commit c373227616bed00f97115d5cab14ede38f3b5223.
tr.point() will now be a canonical point (a point in the base domain)
while here we do not want to have a canonical point
This reverts commit c373227616bed00f97115d5cab14ede38f3b5223.
tr.point() will now be a canonical point (a point in the base domain)
while here we do not want to have a canonical point
Version 2.0 was commit: 5b8b5c21ec18c878a93be2fca95f9c9dafd58ac6
Short version:
Made it work without point/weighted_point implicit conversions
and made it more generic by reworking the inheritance of adaptors and providing
appropriate constructors
Long version:
-- Reworked P3_construct_point_3 and P3_construct_weighted_point_3 to inherit
a base Construct_point_3 and initialize it properly at construction.
-- Renamed Traits_with_offset / Regular_traits_with_offset adaptors. These
classes now inherit the base functor and the constructors allow to initialize
that base from an existing functor (meaning that we don't default constructor
functors anymore). This also means that we can use the base operator() of the
functors and can thus use all possible inputs (with or without offsets).
-- Static filters now probably inherit the correct *_filtered_traits_base_3.
-- All traits classes now have constructor to be able to initialize traits
from a given domain and a given base kernel (rather than default construct)
-- Fixed Del/regular_remove_traits inherting the wrong classes
-- Filtered traits have exact and approximate traits rather than exact and
approximate domains with default constructed traits
One problem is left:
Filtered traits members are initialized with a default constructed base kernel.
Ideally, it should use Cartesian_converter(Base::kernel()), but this does not
exist...
Version 2.0 was commit: 5b8b5c21ec18c878a93be2fca95f9c9dafd58ac6
Short version:
Made it work without point/weighted_point implicit conversions
and made it more generic by reworking the inheritance of adaptors and providing
appropriate constructors
Long version:
-- Reworked P3_construct_point_3 and P3_construct_weighted_point_3 to inherit
a base Construct_point_3 and initialize it properly at construction.
-- Renamed Traits_with_offset / Regular_traits_with_offset adaptors. These
classes now inherit the base functor and the constructors allow to initialize
that base from an existing functor (meaning that we don't default constructor
functors anymore). This also means that we can use the base operator() of the
functors and can thus use all possible inputs (with or without offsets).
-- Static filters now probably inherit the correct *_filtered_traits_base_3.
-- All traits classes now have constructor to be able to initialize traits
from a given domain and a given base kernel (rather than default construct)
-- Fixed Del/regular_remove_traits inherting the wrong classes
-- Filtered traits have exact and approximate traits rather than exact and
approximate domains with default constructed traits
One problem is left:
Filtered traits members are initialized with a default constructed base kernel.
Ideally, it should use Cartesian_converter(Base::kernel()), but this does not
exist...
It was a giant mess of point, construct_point, Point_3, point,
and the same for segment, triangle, tetrahedron.
With this commit :
-- All types are aligned on Point and Point_3, that is the former
may in fact be a K::Weighted_point_3 while the latter is always
a K::Point_3. For example, the type Periodic_segment is a periodic
segment with extremities of type Point (thus possible weighted),
while Periodic_segment_3 has extremities Point_3 (bare points).
-- Functions with 'construct_' in the name will return a
"bare" type (e.g. construct_segment() returns a Segment_3,
construct_periodic_segment() a Periodic_segment_3, etc.).
Functions without 'construct_' will return possibly-weighted
types (e.g. segment() returns a Segment, periodic_segment()
returns a Periodic_segment, etc.).
-- Fixed many duplicates functions
-- Geometric functions now allow all possible inputs (e.g. it is
possible to call construct_point() on a Point, a Point_3, a Periodic_point,
and a Periodic_point_3).
-- Fixed a few bugs:
-- tr.point() will correctly return a Weighted_point when called
from a regular triangulation
-- construct_point() must not be called before the predicates otherwise
we are using the wrong version of the domain (and get wrong filters)
-- Fixed wrong function types (e.g. nearest_power_vertex takes a Bare_point
in argument, not a weighted_point)
It was a giant mess of point, construct_point, Point_3, point,
and the same for segment, triangle, tetrahedron.
With this commit :
-- All types are aligned on Point and Point_3, that is the former
may in fact be a K::Weighted_point_3 while the latter is always
a K::Point_3. For example, the type Periodic_segment is a periodic
segment with extremities of type Point (thus possible weighted),
while Periodic_segment_3 has extremities Point_3 (bare points).
-- Functions with 'construct_' in the name will return a
"bare" type (e.g. construct_segment() returns a Segment_3,
construct_periodic_segment() a Periodic_segment_3, etc.).
Functions without 'construct_' will return possibly-weighted
types (e.g. segment() returns a Segment, periodic_segment()
returns a Periodic_segment, etc.).
-- Fixed many duplicates functions
-- Geometric functions now allow all possible inputs (e.g. it is
possible to call construct_point() on a Point, a Point_3, a Periodic_point,
and a Periodic_point_3).
-- Fixed a few bugs:
-- tr.point() will correctly return a Weighted_point when called
from a regular triangulation
-- construct_point() must not be called before the predicates otherwise
we are using the wrong version of the domain (and get wrong filters)
-- Fixed wrong function types (e.g. nearest_power_vertex takes a Bare_point
in argument, not a weighted_point)
Preparation for rebase on the implicit conversion branch.
Improved consistency on typedefs in P3T3:
-Point: either Gt::Point_3 or Gt::Weighted_point_3
-Point_3: Gt::Point_3
-Periodic_point: a periodic Point
-Periodic_point_3: a periodic Point_3
in P3RT3:
-Bare_point: Gt::Point_3
-Weighted_point: Gt::Weighted_point_3
-Periodic_bare_point: a periodic Bare_point
-Periodic_weighted_point: a periodic Weighted_point
in P3T3, functions:
construct_point: return_type --> Gt::Point_3
point: return_type --> Point
construct_periodic_point: return_type --> Periodic_point_3
periodic_point: return_type --> Periodic_point
in P3RT3, functions:
construct_weighted_point: return_type --> Gt::Weighted_point_3
Preparation for rebase on the implicit conversion branch.
Improved consistency on typedefs in P3T3:
-Point: either Gt::Point_3 or Gt::Weighted_point_3
-Point_3: Gt::Point_3
-Periodic_point: a periodic Point
-Periodic_point_3: a periodic Point_3
in P3RT3:
-Bare_point: Gt::Point_3
-Weighted_point: Gt::Weighted_point_3
-Periodic_bare_point: a periodic Bare_point
-Periodic_weighted_point: a periodic Weighted_point
in P3T3, functions:
construct_point: return_type --> Gt::Point_3
point: return_type --> Point
construct_periodic_point: return_type --> Periodic_point_3
periodic_point: return_type --> Periodic_point
in P3RT3, functions:
construct_weighted_point: return_type --> Gt::Weighted_point_3
BEFORE:
A template mecanism allows to determine wether the kernel offers filtered, or
even statistically filtered operations. The highest level is chosen and includes
the sub-levels. For example, if the kernel offers filtered but _not_ statistically
filtered operations, using the traits class `Periodic_3_triangulation_traits_3`
is equivalent to using the class `Periodic_3_triangulation_filtered_traits_3`,
which inherits the operations of `Periodic_3_triangulation_traits_3` (implemented
in `Periodic_3_triangulation_traits_base_3`) and overwrites some of them.
A similar mecanism is done for Delaunay and regular traits; e.g. if the kernel
offers statistically filtered traits, then using `Periodic_3_Delaunay_triangulation_traits_3`
is similar to using `Periodic_3_Delaunay_triangulation_statistically_filtered_traits_3`,
which inherits from `Periodic_3_Delaunay_triangulation_filtered_traits_3`, which itself
inherits from `Periodic_3_Delaunay_triangulation_traits_3`.
PROBLEM:
The base class of Delaunay and regular traits, respectively
`Periodic_3_Delaunay_triangulation_traits_base_3` and
`Periodic_3_regular_triangulation_traits_base_3` inherit the class
`Periodic_3_triangulation_traits_base_3`. Thus, if the kernel is filtered
or statistically filtered, then the filtered operations that should
"belong" at the level of triangulation traits (for example, orientation_3)
must be duplicated in the Delaunay and regular traits file otherwise
they are not filtered.
AFTER:
With this commit, the Delaunay and regular bases traits inherit
from `Periodic_3_triangulation_traits_3` (no "_base"). This means
that the base class will also select its highest possible level of
filtration and there is no need to duplicate code 3 times anymore.
BEFORE:
A template mecanism allows to determine wether the kernel offers filtered, or
even statistically filtered operations. The highest level is chosen and includes
the sub-levels. For example, if the kernel offers filtered but _not_ statistically
filtered operations, using the traits class `Periodic_3_triangulation_traits_3`
is equivalent to using the class `Periodic_3_triangulation_filtered_traits_3`,
which inherits the operations of `Periodic_3_triangulation_traits_3` (implemented
in `Periodic_3_triangulation_traits_base_3`) and overwrites some of them.
A similar mecanism is done for Delaunay and regular traits; e.g. if the kernel
offers statistically filtered traits, then using `Periodic_3_Delaunay_triangulation_traits_3`
is similar to using `Periodic_3_Delaunay_triangulation_statistically_filtered_traits_3`,
which inherits from `Periodic_3_Delaunay_triangulation_filtered_traits_3`, which itself
inherits from `Periodic_3_Delaunay_triangulation_traits_3`.
PROBLEM:
The base class of Delaunay and regular traits, respectively
`Periodic_3_Delaunay_triangulation_traits_base_3` and
`Periodic_3_regular_triangulation_traits_base_3` inherit the class
`Periodic_3_triangulation_traits_base_3`. Thus, if the kernel is filtered
or statistically filtered, then the filtered operations that should
"belong" at the level of triangulation traits (for example, orientation_3)
must be duplicated in the Delaunay and regular traits file otherwise
they are not filtered.
AFTER:
With this commit, the Delaunay and regular bases traits inherit
from `Periodic_3_triangulation_traits_3` (no "_base"). This means
that the base class will also select its highest possible level of
filtration and there is no need to duplicate code 3 times anymore.
Because the point lies on a vertex does not mean that it is closest to that
vertex for the power distance (e.g. there could be a point with near infinite
weight somewhere else and that point would be the closest)
Because the point lies on a vertex does not mean that it is closest to that
vertex for the power distance (e.g. there could be a point with near infinite
weight somewhere else and that point would be the closest)
This aligns the way Periodic_3_regular_triangulation_3 is built with Triangulation_3's
Regular_triangulation_3: the TDS now uses a Regular_triangulation_vertex_base_3 and
a Weighted_point_mapper_3 wraps the Point_3 type out of the base geometric traits
This aligns the way Periodic_3_regular_triangulation_3 is built with Triangulation_3's
Regular_triangulation_3: the TDS now uses a Regular_triangulation_vertex_base_3 and
a Weighted_point_mapper_3 wraps the Point_3 type out of the base geometric traits
-- A real kernel is now passed to the traits and not some kind of Regular_traits
thus removing the need for Weighted_converter_3 (and similar changes)
-- Updated function objects names
-- A real kernel is now passed to the traits and not some kind of Regular_traits
thus removing the need for Weighted_converter_3 (and similar changes)
-- Updated function objects names
-- Gave Regular_traits_with_offsets_adaptor its own file
-- Updated function objects names
(e.g. power_test_3 -> Power_side_of_oriented_power_sphere_3)
-- Regular_traits_with_offsets_adaptor now has all the required operator()
overloads to avoid losing point weights due to implicit WP->P conversions
-- Periodic_3_regular_triangulation_traits_base_3 now derives from
Periodic_3_triangulation_traits_base_3
-- Gave Regular_traits_with_offsets_adaptor its own file
-- Updated function objects names
(e.g. power_test_3 -> Power_side_of_oriented_power_sphere_3)
-- Regular_traits_with_offsets_adaptor now has all the required operator()
overloads to avoid losing point weights due to implicit WP->P conversions
-- Periodic_3_regular_triangulation_traits_base_3 now derives from
Periodic_3_triangulation_traits_base_3
Followup to:
> commit 535c5bb5b2
> Author: Laurent Rineau <laurent.rineau@cgal.org>
> Date: Wed Apr 6 16:03:55 2016 +0200
>
> Speed-up Triangulation_3::read_cells...
>
> ... by a factor 5 for big triangulations! The old code was using:
>
> std::map<size_t, Vertex_handle> V;
> std::map<size_t, Cell_handle> C;
>
> whereas the indices are contiguous: from 0 to n. `std::vector` is a lot
> better for that use case!
Locate functions returns an Offset indicating the translation to apply on the
periodic geometry object associated to a cell, to get the periodic
geometry object really containing the input point.
Mael Rouxel-Labbé
Sébastien Loriot
Laurent Rineau
Andreas Fabri
Sebastien Loriot
Aymeric Pellé