WIP: Convex hull invalid topology
- Investigation over #311
This adds a test incorrectly passing, this also explores adding rerun for algorithm visualization.
The main cause of the issue is not found, but hopefully a smaller subset of points will lead to easier debugging.
- As a side-experiment, using rerun and logging has been explored in https://github.com/Vrixyz/parry/pull/6.
increasing the epsilon (* 10 = 0.0034526698) from https://github.com/Vrixyz/parry/blob/d5dc99b4760270c5d82d78098b4124b01529b149/src/shape/convex_polyhedron.rs#L234 fixes the test. I'd like to know why exactly though, Ideally we'd have some insurance that previously generated mesh can't trigger this incorrect behaviour.
- Is it this dot? https://github.com/Vrixyz/parry/blob/d5dc99b4760270c5d82d78098b4124b01529b149/src/transformation/convex_hull3/triangle_facet.rs#L125 ; which would make sense for convex hull to return a "perfect"
investigation of epsilon fix
On failing test, The dot product of triangles from offending edges are:
- edge 1: 0.9998717 -> removed
- edge 2: 0.99989235 -> removed
- edge 3: 0.99964637 -> kept (
> 1.0 - 0.0034526698is false)
So this raises the question that increasing the epsilon is probably not enough, as such case could happen again.
Our test case looks like (red edges are removes, so last edge is ambiguous to create a triangle from (results in 2 triangles up and leads to a bigger triangle):
2 options:
- Should we fix the topology when an edge is removed ?
- it's a bit weird to remove those edges if we have obtuse triangles, such as:
- because we will have to recreate a similar face ; or we should remove the other 2 edges.
- removing the other extra edges seem the best path forward. Additionally, I'd expose the epsilon too.
- Should we remove that check altogether?
- unit tests are passing if this is removed.