## Summary of Changes
The main issue is that the functions `point_on_plane()` and
`projection_plane()` return a `PointC3`, whereas you could have a kernel
that uses a custom point type with `PlaneC3` as its plane type. The
correct return type is thus the kernel's point.
I moved the code into PlaneC3, but the really clean fix would be to have
all of this into the function object `Construct_point_on_3`. However, a
lot of required changes immediately get pulled: `Construct_point_on_3`
does not have the Cartesian / Homogeneous split, other overloads do not
have a nice implementation and instead use directly the members in the
Rep, etc.
## Release Management
* Affected package(s): `Cartesian_kernel`
* Issue(s) solved (if any): -
* Feature/Small Feature (if any): -
* License and copyright ownership: no change
## Summary of Changes
The previous implementation defined `Compare_xy_2` as simply
`Compare_xyz_3`. This does define an order over the projected points,
but it has a strong downside: it ignores the direction of the normal, so
its order can be the opposite of the lexicographical order
would give. This new order is in conflict with the existing
`Compare_x_2` and `Compare_y_2`, which take the normal's direction into
account.
(Also with the `Less_x_2`, `Less_y_2`, and `Less_xy_2` family, which
also exist for the projection traits.)
## Release Management
* Affected package(s): `Kernel_23`
* Issue(s) solved (if any): -
* Feature/Small Feature (if any): -
* License and copyright ownership: no change
## Summary of Changes
Fixes warnings/errors. Quite a few are just cherry picking fixes that
were done in master.
## Release Management
* Affected package(s): Various
* Issue(s) solved (if any): -
* Feature/Small Feature (if any): -
* License and copyright ownership: no change
Updated two CGAL examples to use ``std::vector`` instead of plain
C-style arrays for storing points.
Few more examples can be improved the same way to use ``std::vector``
and avoid usage of c-style arrays.
- Min_annulus_d
- Min_circle_2
- Min_ellipse
- Min_sphere_d
## Summary of Changes
This commit addresses a bug in the `detect_vertex_incident_patches`
function of the Polygon Mesh Processing package (file:
`Polygon_mesh_processing/include/CGAL/Polygon_mesh_processing/detect_features.h`).
The original implementation only processed vertices that were incident
to feature edges, leaving non-feature vertices without any recorded
patch IDs. According to the documentation, every vertex should have a
property map entry listing the patch IDs of all incident faces.
To fix this, the conditional check that restricted processing to feature
vertices has been removed. Now, every vertex is examined, and its
incident patch IDs are correctly gathered.
## Release Management
* **Affected package(s):** Polygon Mesh Processing
* **Issue(s) solved:** fix#8730
* **Feature/Small Feature:** Bug fix for complete patch detection on all
vertices
* **Affected file:**
`Polygon_mesh_processing/include/CGAL/Polygon_mesh_processing/detect_features.h`
## Summary of Changes
Removing FindEigen3.cmake as it is outdated and no longer required.
It lacks the definition of the target "Eigen3::Eigen" which is used by
the Ceres library.
## Release Management
* Affected package(s): Installation
> [!WARNING]
> Be careful during **the merge into `6.0.x-branch`**: this PR modifies
CMake files in the Polyhedron demo, that was renamed CGAL Lab for
CGAL-6.0.
## Summary of Changes
Replace a `std::set<Vertex_handle>` by a
`std::set<std::pair<std::size_t,Vertex_handle>>` to make traversing the
set deterministic.
At the same time, do not `erase()` a key, but an `iterator`.
## Release Management
* Affected package(s): Mesh_2
* Issue(s) solved (if any): fix#8719
* License and copyright ownership: unchanged
The previous implementation defined Compare_xy_2 as
simply Compare_xyz_3. This does define an order
over the projected points, but it has a strong downside:
it ignores the direction of the normal, so its order
can be the opposite of the lexicographical order
would give. This new order is in conflict with
the existing Compare_x_2 and Compare_y_2, which
take the normal's direction into account.
(Also with the Less_x_2, Less_y_2, and Less_xy_2
family, which also exist for the projection traits).
There are two use cases:
- either we care about the shifted position (for example for P3M3 where
we will insert the shifted position)
- either we don't care about the shifted position, and we are ok with
point + shifting offset (for example in P3M3 predicates to determine
is_bad)
In the first case, we cannot determine the shift using predicates,
otherwise we could have an inconsitency in the final result:
the predicates say the point is in, but once constructed it is not.
So this commit distinguishes between both. When we care about the
actual shifted position, we construct the point. There might be
numerical errors if we are not using exact constructions, but it
does not really matter.
What should be done better:
- use compare_x/y/z_3 instead of <
- handle the case where the numerical errors are such that you
get a really silly point far from the truth. Maybe this should
all be done in EPECK. There is something like this in the
history of canonicalize_helper.h ....
Sébastien Loriot
Sven Oesau
Mael Rouxel-Labbé
albert-github
Jane Tournois
Sebastien Loriot