Adding 3D barycentric coordinates for convex polyhedra

[sloriot]

Summary of Changes

New package for 3D barycentric coordinates in a convex polyhedron

Release Management

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

[sloriot]

/build:v1

[github-actions]

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

[sloriot]

test/Barycentric_coordinates_3/test_containers fails with

terminate called after throwing an instance of 'CGAL::Assertion_exception'
  what():  CGAL ERROR: assertion violation!
Expr: sum != FT(0)
File: Barycentric_coordinates_3/include/CGAL/Barycentric_coordinates_3/Wachspress_coordinates_3.h
Line: 269
Aborted

I suspect there is a degenerate case not handled as the mesh is cube and the query the centroid of the cube

[sloriot]

cc @antoniospg :)

[danston]

@sloriot No, for center query in a cube there are no edge cases. The sum should be strictly positive because all weights are positive. My guess would be that certain weights are positive and certain are negative so they sum up to zero. If this is a case, most likely the orientation of faces is different from what it has been when the test was developed because it did pass when Antonio worked on it. Could that be that this line

CGAL::make_hexahedron(p0, p1, p2, p3, p4, p5, p6, p7, polyhedron, CGAL::parameters::do_not_triangulate_faces(false));

produces different results from this one:

PMP::triangulate_faces(faces(polyhedron), polyhedron);

In any case for such a simple test, I would first check how the cube looks like, orientation of its faces, and values of the weights.

[sloriot]

What is very strange. If I write the generated mesh into a file, and read it back the test works. address sanitizer does not report anything and CGAL::is_valid_polygon_mesh() does not raise any assertion. It seems that the issue depends on the way elements are stored in the mesh (that is what is the first halfedge visited around a vertex, ...).

[danston]

@sloriot The issue is probably coming from this method. There is suspicious negation of the first face normal, which is not coherent with other normals used here. Implementations of other MV and DH coordinates do not have this. My guess would be that this method does not return the same weights for the same mesh but differently oriented faces, which should not be the case. What is important here is to have consistent normals as indicated in the original paper. Maybe just try to remove the negation in line 296 and see what happens?

There are multiple formulas to compute WP coordinates. I do not remember which one Antonio used here. Maybe it is worth using all formulas from the same paper to be consistent. Finally, another test that is easy to do is to change WP to DH coordinates in this test and see if it works. If I remember correctly for such a simple case (center point in a cube) WP and DH should produce exactly the same result.