Skip to content

Conversation

@sloriot
Copy link
Member

@sloriot sloriot commented Nov 12, 2025

Add experimental functions to compute the kernel of a mesh

Release Management

  • Affected package(s): PMP, BGL
  • Issue(s) solved (if any):
  • Feature/Small Feature (if any):
  • Link to compiled documentation (obligatory for small feature) wrong link name to be changed
  • License and copyright ownership:

@MaelRL MaelRL added this to the 6.2-beta milestone Jan 6, 2026
std::size_t seed = choose_parameter(get_parameter(np, internal_np::random_seed), std::random_device()());

// Immediate exit if the input is not of gender zero to speedup on stupid benchmarks
// if (vertices(pm).size() - edges(pm).size() + faces(pm).size() != 2)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is it no longer active? are you benchmark then wrong?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My benchmark does not contain meshes with genus different from zero and was therefore not impacted. I disabled it to be able to compute the kernel of a mesh with holes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can a mesh with holes have a kernel?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The definition of the kernel is equivalent to the intersection of the halfspaces defined by the faces of the mesh. With this second definition, the kernel is correctly defined and can be used to compute the kernel of only a subpart of a mesh.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that functions like vertices() are only tight on garbage collected meshes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vertices.size() is always tight, num_vertices() is not.

@LeoValque

This comment was marked as outdated.

@github-actions

This comment was marked as outdated.

@LeoValque

This comment was marked as outdated.

@github-actions
Copy link

The documentation is built. It will be available, after a few minutes, here: https://cgal.github.io/9131/v0/Manual/index.html

@MaelRL MaelRL marked this pull request as ready for review January 14, 2026 11:02
@afabri
Copy link
Member

afabri commented Jan 14, 2026

I think it would be reasonable to have as precondition that the surface is a watertight 2manifold with a single connected component. Probably also free of self intersections.

@sloriot sloriot added Not yet approved The feature or pull-request has not yet been approved. Small feature and removed Work in progress labels Jan 15, 2026
@LeoValque
Copy link
Contributor

I think it would be reasonable to have as precondition that the surface is a watertight 2manifold with a single connected component. Probably also free of self intersections.

None of these conditions are required for the functions to operate correctly. Should we specify preconditions that are not strictly necessary?
Side note: the absence of degenerate faces is a required precondition.

@afabri
Copy link
Member

afabri commented Jan 15, 2026

As Leo just explained me, when the surface is open, the kernel could be an unbounded polytope. Therefore the algorithm clips with the bounding box of the vertices. This must be either documented, or the function could have as second parameter a bounding object. @sloriot ???

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants