Updated benchmark documentation.

Author: Jaybro

docs/benchmark.md

@@ -4,15 +4,9 @@ One of the PicoTree examples is a small [benchmark](../examples/benchmark/) that
 
 # Data sets
 
-The [Robotic 3D Scan Repository](http://kos.informatik.uni-osnabrueck.de/3Dscans/) provides several 3D point clouds. The following two have been used for the comparison benchmark:
+The [Robotic 3D Scan Repository](http://kos.informatik.uni-osnabrueck.de/3Dscans/) provides several 3D point clouds that have been generated using a LiDAR scanner. The following has been used for the comparison benchmark:
 
-* #25 - Würzburg marketplace. Authors: Johannes Schauer, Andreas Nüchter from the University of Würzburg, Germany.
-* #26 - Maria-Schmerz-Kapelle Randersacker. Authors: Andreas Nüchter, Helge Andreas Lauterbach from the University of Würzburg, Germany.
-
-Both have been generated using a LiDAR scanner and represent different types of environments. The running time of the benchmark was kept reasonable by using a subset of points and storing those in a simple binary format. The final point cloud sizes were as follows:
-
-* #25 - Würzburg marketplace: 13729039 points.
-* #26 - Maria-Schmerz-Kapelle Randersacker: 20793160 points.
+* #21 - Bremen Gaussian Point. Authors: Dorit Borrmann and Andreas Nüchter from Jacobs University Bremen gGmbH, Germany.
 
 # Results
 
@@ -21,43 +15,38 @@ The different KdTree implementations are compared to each other with respect to
 * Build algorithm: Compile-time vs. run-time tree dimension for the following building techniques:
   * Nanoflann Midpoint variation.
   * PicoTree Sliding Midpoint (along the longest axis).
-  * PicoTree Longest Axis Median.
-* Radius search algorithm: The radius in meters divided by 10 (i.e. 0.2m and 0.4m).
+* Radius search algorithm: The radius in meters divided by 10 (i.e. 1.5m and 3.0m).
 * Knn algorithm: The amount of neighbors searched.
-  * For a "special" case of the knn algorithm, where `k` is set to `1`, the search speed is compared with respect to the three previously mentioned tree building techniques.
-
-Note that the run time describes a single invocation of a build algorithm and n invocations of the others.
-
-It is interesting to see that finding a single nearest neighbor can be quite a bit faster using the Longest Axis Median splitting technique. However, building the tree or querying multiple neighbors is slower. The extra time it takes to build the tree is no longer a factor when the tree is queried multiple times (on the test sets this was about `2n-4n` times). This means the splitting technique can be useful in combination with an algorithm like [ICP](https://en.wikipedia.org/wiki/Iterative_closest_point).
 
-Results were generated on: 12-04-2021 using MinGW GCC 10.1.
-
-## #25 - Würzburg marketplace.
+The running time of the benchmark was kept reasonable by using two subsets of points and storing those in a simple binary format. The final point cloud sizes were as follows:
 
-![Square Build Time](./images/benchmark_square_build_time.png)![Square Radius Search Time](./images/benchmark_square_radius_search_time.png)
+* Part 1: 7733372 points.
+* Part 2: 7200863 points.
 
-![Square Knn Search Time](./images/benchmark_square_knn_search_time.png)![Square Knn1 Search Time](./images/benchmark_square_knn1_search_time.png)
+Both parts are 360 degree scans taken from different positions. The first is used to build a tree and the second for querying that tree. Note that each run time describes a single invocation of a build algorithm and n invocations of the others.
 
-## #26 - Maria-Schmerz-Kapelle Randersacker.
+Results were generated on: 12-04-2021 using MinGW GCC 10.1.
 
-![Square Build Time](./images/benchmark_church_build_time.png)![Square Radius Search Time](./images/benchmark_church_radius_search_time.png)
+![Build Time](./images/benchmark_gauss_build_time.png)![Radius Search Time](./images/benchmark_gauss_radius_search_time.png)
 
-![Square Knn Search Time](./images/benchmark_church_knn_search_time.png)![Square Knn1 Search Time](./images/benchmark_church_knn1_search_time.png)
+![Knn Search Time](./images/benchmark_gauss_knn_search_time.png)
 
 # Running a new benchmark
 
-The following steps can be taken to reproduce the data sets:
+The following steps can be taken to generate data sets:
+
+1. Download and unpack a data set. This results in a directory containing pairs of `.3d` and `.pose` files, each representing a LiDAR scan.
+2. Select any of the scans (corresponding pairs of `.3d` and `.pose` files) to compile into a binary.
+3. Run the `uosr_to_bin` executable as a sibling to the selected scans to generate a `scans.bin` file.
+4. Two point clouds are required for a benchmark. The first should be named `scans0.bin` and the second `scans1.bin`.
 
-1. Download and unpack a data set. This results in a directory containing several pairs of `.3d` and `.pose` files, each representing a LiDAR scan.
-2. Delete all scans but the first one (only keeping `scan000.3d` and `scan000.pose`).
-3. Run the `uosr_to_bin` executable as a sibling to the scan to generate a `scans.bin` file.
+To reproduce the exact point clouds used by the benchmark on the Bremen Gaussian Point dataset, use scans 0-8 for the first cloud and scans 9-17 for the second.
 
 To get performance statistics:
 
-4. Run the `benchmark` executable as a sibling to the `scans.bin` file and set the output format to `json`.
-5. Run `plot_benchmarks.py` to show and store the performance plots (requires Python with [Matplotlib](https://matplotlib.org/)).
+5. Run the `bm_pico_kd_tree` or `bm_nanoflann` executables as a sibling to the `scans.bin` file and set the output format to `json`.
+6. Run `plot_benchmarks.py` to show and store the performance plots (requires Python with [Matplotlib](https://matplotlib.org/)).
 
 Note the following:
 
-* The `uosr_to_bin` tool simply combines all pairs of `.3d` and `.pose` files into a single `.bin` file. This means a bigger point cloud can be used for benchmarking.
-* A `.txt` file can be generated from the `.bin` file by running the `bin_to_ascii` executable (as a sibling to the binary file). Each line in the output file is a 3D point.
+* A `scans.txt` file can be generated from the `scans.bin` file by running the `bin_to_ascii` executable (as a sibling to the binary file). Each line in the output file is a 3D point.