For point types/feature types that do not have xyz information, PCL currently relies on the external search libraries FLANN and nanoflann. However, it would be nice to have some fallback search method that is available even if neither FLANN nor nanoflann is installed. The fallback method does not have to be fast, it is just to have some option without relying on external libraries. The BruteForce class could be an option for that, however it currently only supports types with xyz information (see e.g. the getDistSqr function: https://github.com/PointCloudLibrary/pcl/blob/master/search/include/pcl/search/impl/brute_force.hpp#L46 ). For non-xyz types, it would probably have to make use of the PointRepresentation class, to convert a point/feature to a vector/array for computing the distance. Ideally, BruteForce should decide at compile-time (maybe with if constexpr?) whether it can use getVector3fMap like before or has to use PointRepresentation::vectorize.
So tasks are:
- investigate what would have to be changed in
BruteForce to support non-xyz point/features types, post the findings here (no extensive code, just the ideas, so that we can decide if that is a good way to move forward)
- extend the tests in test/search to make sure that the adapted
BruteForce class gives the same results as either KdTree or KdTreeNanoflann on 1-2 feature types (for inspiration, test_kdtree_nanoflann.cpp might be a starting point)
- create a pull request
If you have any questions, feel free to ask.
For point types/feature types that do not have xyz information, PCL currently relies on the external search libraries FLANN and nanoflann. However, it would be nice to have some fallback search method that is available even if neither FLANN nor nanoflann is installed. The fallback method does not have to be fast, it is just to have some option without relying on external libraries. The
BruteForceclass could be an option for that, however it currently only supports types with xyz information (see e.g. thegetDistSqrfunction: https://github.com/PointCloudLibrary/pcl/blob/master/search/include/pcl/search/impl/brute_force.hpp#L46 ). For non-xyz types, it would probably have to make use of thePointRepresentationclass, to convert a point/feature to a vector/array for computing the distance. Ideally,BruteForceshould decide at compile-time (maybe withif constexpr?) whether it can usegetVector3fMaplike before or has to usePointRepresentation::vectorize.So tasks are:
BruteForceto support non-xyz point/features types, post the findings here (no extensive code, just the ideas, so that we can decide if that is a good way to move forward)BruteForceclass gives the same results as eitherKdTreeorKdTreeNanoflannon 1-2 feature types (for inspiration, test_kdtree_nanoflann.cpp might be a starting point)If you have any questions, feel free to ask.