Normal orientation issues in complex geometries

[eugeniovaretti]

Type

• Bug fix (non-breaking change which fixes an issue): Fixes #
• New feature (non-breaking change which adds functionality). Resolves #
• Breaking change (fix or feature that would cause existing functionality to not work as expected) Resolves #

Motivation and Context

While exploring existing algorithms for creating meshes from point clouds, we came across Open3D. We noticed that one of the test point clouds we had available failed to reconstruct the mesh using the normal estimation method. We investigated and studied the library regarding the methods we used, and consequently identified some weaknesses in the algorithm.

Our work is documented in this report.

Given an input point cloud, the algorithm processes the data primarily based on Euclidean distance, using the K-nearest neighbors (KNN) algorithm as a basis. In the case of specific geometries, this can be problematic when orienting two distinct surfaces of the same volume that should have opposite orientations (e.g., cusps, stenosis, etc.).

Therefore, we provide the user with the ability to manipulate two parameters in the OrientNormalsConsistentTangentPlane function (or orient_normals_consisten_tangent_plane in Python), namely lambda and cos_alpha_tol, which respectively allow for a penalty and a threshold on the distance of a point x from the plane defined by a point z and its estimated normal $n_z$ (calculated in the EstimateNormal method).

All the work is documented in the report.

Checklist:

• I have run python util/check_style.py --apply to apply Open3D code style
  to my code.
• This PR changes Open3D behavior or adds new functionality.
  • Both C++ (Doxygen) and Python (Sphinx / Google style) documentation is
    updated accordingly.
  • I have added or updated C++ and / or Python unit tests OR included test
    results (e.g. screenshots or numbers) here.
• I will follow up and update the code if CI fails.
• For fork PRs, I have selected Allow edits from maintainers.

Description

Below we show some of the results and improvements that follow from this modification. By using the default values for the (new) parameters, no macroscopic changes will be applied to the original algorithm.
Only a minor modification has been made to the code, specifically the initial point of traversal_queue.
All the details and motivations are provided in the report.

Original Algorithm:

Our changes:

Differences:

Unit Tests

All unit tests related to our modifications (PointCloud*) have passed successfully.

Authors

This pull request is the culmination of exceptional teamwork within an outstanding team, including @SimonePiazza99 and @federicavalentini99.

---

This change is 

[update-docs]

Thanks for submitting this pull request! The maintainers of this repository would appreciate if you could update the CHANGELOG.md based on your changes.

[yuecideng]

Hi @eugeniovaretti , thanks for your work, which looks useful to achieve better normals orientation. Could you provide the full code to reproduce the results you have shown in the plots?

Our work is the result of a project for the Politecnico di Milano, and it is documented in [this report](will be available by June 19, 2023).

Looking forward to see your report.

[benjaminum]

@eugeniovaretti Can you share your report?

[eugeniovaretti]

Good morning, everyone,
sorry for the delay in replying, this period has been a bit full.
We are waiting for the go-ahead from the professor to make the report and the repository public.

[reyanshsolis]

Interesting work! Waiting on the report. Thanks for your valuable contribution.

[eugeniovaretti]

Good morning everyone. We finally got the green light to publish our project. Find the report and the link to the reproducibility folder here: https://eugeniovaretti.github.io/meshreco/

[benjaminum]

Good morning everyone. We finally got the green light to publish our project. Find the report and the link to the reproducibility folder here: https://eugeniovaretti.github.io/meshreco/

Thank you @eugeniovaretti ! Will check out the report

[benjaminum]

@eugeniovaretti what will happen if we set the angle threshold to zero? Zero is obviously not a good choice, I am just interested in the effect. Will it crash or behave randomly?

[eugeniovaretti]

@benjaminum As you can see in the attached pic it will behave "randomly", as each edge of the graph will be weighted equally (infinity) and the reconstruction will depend on the implementation of Kruskal's algorithm (which will select one of the multiple connected graphs with minimum weight).

[benjaminum]

@eugeniovaretti That's good. Wanted to be sure that there is no crash in this specific case. The only thing missing is adding documentation for the python part. Do you think you could add documentation similar to the RaycastingScene and add an example of how to use the new parameters?

Open3D/cpp/pybind/t/geometry/raycasting_scene.cpp

Line 17 in b7f9f3a

py::class_<RaycastingScene> raycasting_scene(m, "RaycastingScene", R"doc(

[eugeniovaretti]

@benjaminum We have just added the Python documentation. Hope everything is ok.

[benjaminum]

Reviewable status: 0 of 6 files reviewed, all discussions resolved (waiting on @yuecideng)