Skip to content

Bind Surface_mesh_shortest_path (exact polyhedral geodesic) alongside Heat_method_3 #78

Description

@jf---

compas_cgal.geodesics currently binds only Heat_method_3HeatGeodesicSolver, heat_geodesic_distances, geodesic_isolines, geodesic_isolines_split.

CGAL also ships Surface_mesh_shortest_path, the exact MMP polyhedral geodesic. It isn't exposed, so downstream projects that need exact distances add pygeodesic — a second compiled dependency wrapping the same algorithm, with its own wheel per platform and no type stubs, next to a CGAL that already contains it.

Why it matters beyond convenience: the heat method is an approximation, so any project validating it needs an exact oracle. Today that oracle must come from outside CGAL, which means the reference and the thing under test have different provenance. That's exactly backwards for accuracy work — and it's the situation that made compas_cgal #73 / CGAL hard to characterise, since the fold in value_at_source_set had to be measured against a foreign implementation.

Shape: Surface_mesh_shortest_path takes source points (vertex or face-barycentric) and answers distance_to_source_points() over the mesh, so it fits the existing heat_geodesic_distances(mesh, sources) -> NDArray signature closely enough to sit beside it. A single exact_geodesic_distances(mesh, sources) would cover the oracle use directly.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions