Improved performance of function geometry::PointCloud::RemoveRadiusOutliers, function geometry::ClusterDBSCAN and feature counting

[PiatrouskiIM]

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

Performance improvements.

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

1. Determining the presence of a sufficient number of neighbors in a given radius in the geometry::PointCloud::RemoveRadiusOutliers function can be carried out by the SearchHybrid function instead of the SearchRadius function.
   2.0 When clustering in PointCloud::ClusterDBSCAN, a set of visited points is created for each new cluster. Elements are added to this set based on the presence of a certain label. This set is subsequently used to add elements to the set of unvisited points. The same thing can be done much more efficiently based only on labels.
   2.1 And there is also no need to represent the collection of unvisited points as an unordered set, given that the only difference is the additional protection against duplication when adding a new element.
2. When counting features in ComputePairFeatures, angles are compared, but given that the arc cosine is a monotonically decreasing function, its influence on the comparison result is limited to a change in sign.

[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.

[ssheorey]

Hi @PiatrouskiIM thanks for this optimization! Can you provide some benchmark results of speed comparisons with the code in the main branch? You can use any reasonably sized data (eg something from the data module should be useful).

[benjaminum]

@PiatrouskiIM SearchHybrid is implemented on top of radius search. Can you give an idea of which changes contribute the most to the performance improvement?

[PiatrouskiIM]

I was mistaken about the presence of performance improvements when switching to SearchHybrid (my tests sets were regenerated when running benchmark of the another implementation).

[PiatrouskiIM]

@benjaminum, SearchHybrid is implemented on top of SearchKNN, which is usually implemented differently (I won’t say for nanoflann, but I saw the implementation from scipy written in c). I was wrong about improving performance; it’s more likely a trade-off in favor of searching by radius. There are improvements only if there are many more points in the radius than the set threshold. I can prepare a more detailed comparison to find a visual tradeoff, but it seems that most often searching by radius is almost twice as fast.

[benjaminum]

Sounds good. Looking forward to the comparison!