TriangulationCellBase_3 does not request a circumcenter;
DelaunayTriangulationCellBase_3 does.
Delaunay_triangulation_3 only compiled because
Triangulation_cell_base_3 (and Triangulation_ds_cell_base_3 !)
provided circumcenter() operators and DT3 inherited T3's TDS.
- The circumcenter() functions are removed where they shouldn't exist
- DT3 uses DT_cell_base_3 as cell base instead of T_cell_base_3
- Concepts/Classes that supposedly only required TriangulationCellBase_3
and then built Delaunay triangulations with that (Alpha Shapes, etc.)
are upgraded to request DelaunayTriangulationCellBase_3 (anyway, it
wouldn't compile if you actually provided a model of
TriangulationCellBase_3)
- Fixed various wrong templates in classes/concepts such as
MeshVertexBase_3 not refining RegularTriangulationVertexBase_3
and (only in the doc) defaulting to Triangulation_vertex_base_3
- Removed the deprecated class (for 4+ years) T_cell_base_with_circumcenter
If the input point set is degenerate, dimension() < 3 is always 'true'
and we will eventually try to read beyond the end of the points vector.
See issue https://github.com/CGAL/cgal/issues/2922
When manually building a triangulation, we might have inserted vertices but
not yet cells, and thus the dimension is 0 but point() should still work.
This is the case in tet_soup_to_c3t3 for example.
This wrapper around Regular_triangulation_3 adds undocumented, straightforward
functions which are required for Mesh_3 because of Periodic_3_mesh_3:
they are functions for which both (periodic and non-periodic) triangulations
have fundamentally different implementations, usually because Periodic_3_mesh_3
does not know the offset of a point and must brute-force check all
possibilities. To allow Periodic_3_mesh_3 to use Mesh_3's files,
each mesh triangulation implements its own version.
-- Do not use concept names as template names in the doc
-- Fixed point / point_3 issues and other problems of coherence between concept
and model
-- Fixed some wrong refinement relationships
When the geom_traits given as parameter of `circumcenter` and/or
`weighted_circumcenter` was deriving from the cell base GT
(first template parameter), the gt was up-casted to the
cell base GT, and the function construct_circumcenter_3_object()
(or construct_weighted_circumcenter_3_object()) not
called on the right geom traits type --> possibly missing
the actual input of the function (the robust_circumcenter_traits in Mesh_3)
we add a static assert to check at compile time that point types are the same
When the geom_traits given as parameter of `circumcenter` and/or
`weighted_circumcenter` was deriving from the cell base GT
(first template parameter), the gt was up-casted to the
cell base GT, and the function construct_circumcenter_3_object()
(or construct_weighted_circumcenter_3_object()) not
called on the right geom traits type --> possibly missing
the actual input of the function (the robust_circumcenter_traits in Mesh_3)
we add a static assert to check at compile time that both geom traits
are compatible
Downside: we copy points at each comparison, which is terrible! No noticeable
changes when profiling the construction of a triangulation.
We need this copy because of Lazy kernel: despite construct_point_3 having
const Point_3& construct_point_3_object()(const Point_3&)
the Lazy kernel can return some copies.
Other solutions that were not used:
-- Distinguish the Ouput type of Unary_function_to_property map depending on
the type of Kernel (ugly and not safe)
-- Use Weighted_point_mappers traits (but that blood will not be on my hands)
Triangulation_cell_base_3 cannot be used anymore as a cell base of a regular
triangulation and thus there is no point keeping these functions.
People wishing to disable caching of hidden points in regular triangulations
should use the new policy, see commit b92528171c)
Before WP<->P implicit conversion changes, one could choose to not keep hidden
points by using `Triangulation_cell_base_3` as cell base instead of
`Regular_triangulation_cell_base_3`. This is not possible anymore as point types
will conflict.
This changes introduces a new template parameter to pass a policy on whether
to keep or discard hidden points.
It is a breaking change since it is placed before the container template
parameter, but it makes more sense that way and the container type template
was not documented.
There is no need anymore for sneaky traits adaptors to make Triangulation_3
a compatible base of Regular_triangulation_3:
- The Point type in Triangulation_3 is obtained through TDS::Vertex::Point (see
commit 13d5e89)
- Triangulation_3 always ensures that we are passing bare points to the kernel
functors that require bare point arguments (see commit db5da73)
This greatly clarifies the code of Regular_triangulation_3: there is only a
single traits type, a single base type, etc.
Note that if the type `Point` is already `Point_3`, Construct_point_3 does not
do anything (except in the lazy kernel, but in that case, the running time is
horrible anyway).
Since we have a distinc vertex_base for regular triangulations and that this
regular vertex base defines a type Point, it is redundant to get the Point
type from the Geom_traits.
This also allows to remove the Weighted_point_mapper trick, and pass more easily
custom point types.
The functor members cannot be references because the Regular_triangulation
might be templated by a traits class that is not simply a Kernel (that is
the case in the package Interpolation).
When that is the case, calling this->K::function_object() might be a call
to a constructor in the base traits class. Thus, the functor members
of Reg_traits_adaptors get initialized to temporaries, which is problematic
because these temporaries are at a much lower scope and thus are quickly
cleaned, leaving us with references to nothing in Reg_traits_adaptor.
-- Code added as consequence of disabling implicit conversion between points and
weighted points implies that defining
typedef weighted_point point;
creates ambiguous functors.
This typedef is nevertheless still used, in Weighted_point_mappers.
-- The traits are not supposed to define Bare_point
Instead of calling Criteria(element), one must now call Criteria(tr, element).
The idea is that the triangulation should be responsible of geometric data
while elements only handle connectivity (using ids for example).
This is already the case for Periodic_3_mesh_3 which must obtain
"true" geometric information through the (periodic) triangulation class's
methods.
These changes are transparent for Mesh_3 but allow Periodic_3_mesh_3 to use
Mesh_3's criteria.
-- Do not use concept names as template names in the doc
-- Fixed point / point_3 issues and other problems of coherence between concept
and model
-- Fixed some wrong refinement relationships
When the geom_traits given as parameter of `circumcenter` and/or
`weighted_circumcenter` was deriving from the cell base GT
(first template parameter), the gt was up-casted to the
cell base GT, and the function construct_circumcenter_3_object()
(or construct_weighted_circumcenter_3_object()) not
called on the right geom traits type --> possibly missing
the actual input of the function (the robust_circumcenter_traits in Mesh_3)
we add a static assert to check at compile time that point types are the same
When the geom_traits given as parameter of `circumcenter` and/or
`weighted_circumcenter` was deriving from the cell base GT
(first template parameter), the gt was up-casted to the
cell base GT, and the function construct_circumcenter_3_object()
(or construct_weighted_circumcenter_3_object()) not
called on the right geom traits type --> possibly missing
the actual input of the function (the robust_circumcenter_traits in Mesh_3)
we add a static assert to check at compile time that both geom traits
are compatible
Downside: we copy points at each comparison, which is terrible! No noticeable
changes when profiling the construction of a triangulation.
We need this copy because of Lazy kernel: despite construct_point_3 having
const Point_3& construct_point_3_object()(const Point_3&)
the Lazy kernel can return some copies.
Other solutions that were not used:
-- Distinguish the Ouput type of Unary_function_to_property map depending on
the type of Kernel (ugly and not safe)
-- Use Weighted_point_mappers traits (but that blood will not be on my hands)
Triangulation_cell_base_3 cannot be used anymore as a cell base of a regular
triangulation and thus there is no point keeping these functions.
People wishing to disable caching of hidden points in regular triangulations
should use the new policy, see commit b92528171c)
Before WP<->P implicit conversion changes, one could choose to not keep hidden
points by using `Triangulation_cell_base_3` as cell base instead of
`Regular_triangulation_cell_base_3`. This is not possible anymore as point types
will conflict.
This changes introduces a new template parameter to pass a policy on whether
to keep or discard hidden points.
It is a breaking change since it is placed before the container template
parameter, but it makes more sense that way and the container type template
was not documented.
There is no need anymore for sneaky traits adaptors to make Triangulation_3
a compatible base of Regular_triangulation_3:
- The Point type in Triangulation_3 is obtained through TDS::Vertex::Point (see
commit 13d5e89)
- Triangulation_3 always ensures that we are passing bare points to the kernel
functors that require bare point arguments (see commit db5da73)
This greatly clarifies the code of Regular_triangulation_3: there is only a
single traits type, a single base type, etc.
Note that if the type `Point` is already `Point_3`, Construct_point_3 does not
do anything (except in the lazy kernel, but in that case, the running time is
horrible anyway).
Since we have a distinc vertex_base for regular triangulations and that this
regular vertex base defines a type Point, it is redundant to get the Point
type from the Geom_traits.
This also allows to remove the Weighted_point_mapper trick, and pass more easily
custom point types.
The functor members cannot be references because the Regular_triangulation
might be templated by a traits class that is not simply a Kernel (that is
the case in the package Interpolation).
When that is the case, calling this->K::function_object() might be a call
to a constructor in the base traits class. Thus, the functor members
of Reg_traits_adaptors get initialized to temporaries, which is problematic
because these temporaries are at a much lower scope and thus are quickly
cleaned, leaving us with references to nothing in Reg_traits_adaptor.
-- Code added as consequence of disabling implicit conversion between points and
weighted points implies that defining
typedef weighted_point point;
creates ambiguous functors.
This typedef is nevertheless still used, in Weighted_point_mappers.
-- The traits are not supposed to define Bare_point
-- Do not use concept names as template names in the doc
-- Fixed point / point_3 issues and other problems of coherence between concept
and model
-- Fixed some wrong refinement relationships
When the geom_traits given as parameter of `circumcenter` and/or
`weighted_circumcenter` was deriving from the cell base GT
(first template parameter), the gt was up-casted to the
cell base GT, and the function construct_circumcenter_3_object()
(or construct_weighted_circumcenter_3_object()) not
called on the right geom traits type --> possibly missing
the actual input of the function (the robust_circumcenter_traits in Mesh_3)
we add a static assert to check at compile time that point types are the same
When the geom_traits given as parameter of `circumcenter` and/or
`weighted_circumcenter` was deriving from the cell base GT
(first template parameter), the gt was up-casted to the
cell base GT, and the function construct_circumcenter_3_object()
(or construct_weighted_circumcenter_3_object()) not
called on the right geom traits type --> possibly missing
the actual input of the function (the robust_circumcenter_traits in Mesh_3)
we add a static assert to check at compile time that both geom traits
are compatible
Downside: we copy points at each comparison, which is terrible! No noticeable
changes when profiling the construction of a triangulation.
We need this copy because of Lazy kernel: despite construct_point_3 having
const Point_3& construct_point_3_object()(const Point_3&)
the Lazy kernel can return some copies.
Other solutions that were not used:
-- Distinguish the Ouput type of Unary_function_to_property map depending on
the type of Kernel (ugly and not safe)
-- Use Weighted_point_mappers traits (but that blood will not be on my hands)
Triangulation_cell_base_3 cannot be used anymore as a cell base of a regular
triangulation and thus there is no point keeping these functions.
People wishing to disable caching of hidden points in regular triangulations
should use the new policy, see commit b92528171c)
Before WP<->P implicit conversion changes, one could choose to not keep hidden
points by using `Triangulation_cell_base_3` as cell base instead of
`Regular_triangulation_cell_base_3`. This is not possible anymore as point types
will conflict.
This changes introduces a new template parameter to pass a policy on whether
to keep or discard hidden points.
It is a breaking change since it is placed before the container template
parameter, but it makes more sense that way and the container type template
was not documented.
There is no need anymore for sneaky traits adaptors to make Triangulation_3
a compatible base of Regular_triangulation_3:
- The Point type in Triangulation_3 is obtained through TDS::Vertex::Point (see
commit 13d5e89)
- Triangulation_3 always ensures that we are passing bare points to the kernel
functors that require bare point arguments (see commit db5da73)
This greatly clarifies the code of Regular_triangulation_3: there is only a
single traits type, a single base type, etc.
Note that if the type `Point` is already `Point_3`, Construct_point_3 does not
do anything (except in the lazy kernel, but in that case, the running time is
horrible anyway).
Since we have a distinc vertex_base for regular triangulations and that this
regular vertex base defines a type Point, it is redundant to get the Point
type from the Geom_traits.
This also allows to remove the Weighted_point_mapper trick, and pass more easily
custom point types.
The functor members cannot be references because the Regular_triangulation
might be templated by a traits class that is not simply a Kernel (that is
the case in the package Interpolation).
When that is the case, calling this->K::function_object() might be a call
to a constructor in the base traits class. Thus, the functor members
of Reg_traits_adaptors get initialized to temporaries, which is problematic
because these temporaries are at a much lower scope and thus are quickly
cleaned, leaving us with references to nothing in Reg_traits_adaptor.
-- Code added as consequence of disabling implicit conversion between points and
weighted points implies that defining
typedef weighted_point point;
creates ambiguous functors.
This typedef is nevertheless still used, in Weighted_point_mappers.
-- The traits are not supposed to define Bare_point
When the geom_traits given as parameter of `circumcenter` and/or
`weighted_circumcenter` was deriving from the cell base GT
(first template parameter), the gt was up-casted to the
cell base GT, and the function construct_circumcenter_3_object()
(or construct_weighted_circumcenter_3_object()) not
called on the right geom traits type --> possibly missing
the actual input of the function (the robust_circumcenter_traits in Mesh_3)
we add a static assert to check at compile time that point types are the same
Downside: we copy points at each comparison, which is terrible! No noticeable
changes when profiling the construction of a triangulation.
We need this copy because of Lazy kernel: despite construct_point_3 having
const Point_3& construct_point_3_object()(const Point_3&)
the Lazy kernel can return some copies.
Other solutions that were not used:
-- Distinguish the Ouput type of Unary_function_to_property map depending on
the type of Kernel (ugly and not safe)
-- Use Weighted_point_mappers traits (but that blood will not be on my hands)
Triangulation_cell_base_3 cannot be used anymore as a cell base of a regular
triangulation and thus there is no point keeping these functions.
People wishing to disable caching of hidden points in regular triangulations
should use the new policy, see commit b92528171c)
Before WP<->P implicit conversion changes, one could choose to not keep hidden
points by using `Triangulation_cell_base_3` as cell base instead of
`Regular_triangulation_cell_base_3`. This is not possible anymore as point types
will conflict.
This changes introduces a new template parameter to pass a policy on whether
to keep or discard hidden points.
It is a breaking change since it is placed before the container template
parameter, but it makes more sense that way and the container type template
was not documented.
There is no need anymore for sneaky traits adaptors to make Triangulation_3
a compatible base of Regular_triangulation_3:
- The Point type in Triangulation_3 is obtained through TDS::Vertex::Point (see
commit 13d5e89)
- Triangulation_3 always ensures that we are passing bare points to the kernel
functors that require bare point arguments (see commit db5da73)
This greatly clarifies the code of Regular_triangulation_3: there is only a
single traits type, a single base type, etc.
Note that if the type `Point` is already `Point_3`, Construct_point_3 does not
do anything (except in the lazy kernel, but in that case, the running time is
horrible anyway).
Since we have a distinc vertex_base for regular triangulations and that this
regular vertex base defines a type Point, it is redundant to get the Point
type from the Geom_traits.
This also allows to remove the Weighted_point_mapper trick, and pass more easily
custom point types.
The functor members cannot be references because the Regular_triangulation
might be templated by a traits class that is not simply a Kernel (that is
the case in the package Interpolation).
When that is the case, calling this->K::function_object() might be a call
to a constructor in the base traits class. Thus, the functor members
of Reg_traits_adaptors get initialized to temporaries, which is problematic
because these temporaries are at a much lower scope and thus are quickly
cleaned, leaving us with references to nothing in Reg_traits_adaptor.
-- Code added as consequence of disabling implicit conversion between points and
weighted points implies that defining
typedef weighted_point point;
creates ambiguous functors.
This typedef is nevertheless still used, in Weighted_point_mappers.
-- The traits are not supposed to define Bare_point
because cell_iterator should not return more than one cell with the
same entry point (useful in the case where the entry vertex, edge,
or facet is traversed exactly)
previous commit was dealing with the case where entry is a vertex,
here we deal with all entry types
PLUS fix the edge - facet - vertex degenerate case
when the query segment passes exactly through a vertex, avoid returning more
than one cell containing this vertex
operator++ iterates until it finds a cell which does not contain this vertex
This reverts commit 8b68ab3459.
# Conflicts:
# Triangulation_3/include/CGAL/Triangulation_segment_traverser_3.h
NOTE
in the degenerate case where the query passes exactly through an edge
(i.e. through both of its vertices), it could happen that the iterator
"circulates" around the edge, whithout finding a way to get out of this
infinite loop
randomness is re-introduced to avoid this
when the query segment goes exactly through a facet, the succession of
simplices should be : edge - facet - edge
however, cell_iterator iterate over both of the cells incident to the
facet in question
so, we skip the 2nd one
this new iterator is similar to Triangulation_segment_cell_iterator_3,
but iterates over simplices of all dimensions instead of only cells.
if [source, target] crosses cell1, and enters cell2 via their common
vertex v,
then the iterator returns cell1, v, and cell2 successively
@janetournois @afabri
That commit will fix both runtime errors in Interpolation and
compilation errors in KDS:
- in Interpolation, the traits class carries a normal vector: it needs
to be passed to the RT traits class as well,
- Same in KDS: the compilation error was saying that the constructor
of RT_euclidian_traits_3 must initialize it base class.
Alpha_shapes_3 needs to know a lot about its template parameter `Dt`. To
simplify the code, I have chosen to make the typedef `Tr_Base` public in
3D Delaunay and Regular triangulations.
and fix constructors from Regular_triangulation_3
Revert "introduce Has_nested_type_Bare_point to keep backward compatible"
This reverts part of the commit 98b43b1a49fb2dfb3baee0a532bf5d097f2f4ebd.
Laurent Rineau
Maxime Gimeno
Andreas Fabri
Guillaume Damiand
Mael Rouxel-Labbé
Sébastien Loriot
Jane Tournois
Clement Jamin