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 ....
Sebastien Loriot
Mael Rouxel-Labbé
albert-github
Camille Lanuel
Sven Oesau
Jane Tournois
Sebastien Loriot
Jane Tournois