3dmatch Toolbox

What 3DMatch gives you that most 3D matching write-ups don't is a defensible, reproducible number. The Keypoint Matching Benchmark leaderboard keeps separate lanes for 2D-based, 3D-based, color-using and depth-using methods, so a new descriptor is compared honestly rather than against whatever baseline flatters it, and the baselines are real: FPFH (ICRA 2009) and Spin-Images (PAMI 1999). The 0.3m3 interest-point bounding box, the 30x30x30 TDF voxel grid at 0.01m and the per-patch metadata (framePath, pixelCoords, camCoords, camK, colorPatch, depthPatch, voxelGridTDF) are all documented, which means you can reproduce the pipeline yourself rather than trusting a black box. The training story is the clever part and the part that dates fastest. The unsupervised feature-learning trick — harvesting correspondence labels from existing RGB-D reconstructions instead of annotating — is why this worked at all in 2016, and it generalizes: the authors report transfer to instance-level object model alignment for the Amazon Picking Challenge and to mesh surface correspondence, across different spatial scales. The honest limits are structural. The reported baseline is depth-only, so color-critical matching is out of scope even though the leaderboard invites color-using entries. You bring keypoint detection, patch extraction, correspondence pruning and registration. Training assumes substantial GPU compute. And the codebase is frozen in its publication era — C++/CUDA/Matlab, not a maintained Python package. Where it fits: a researcher or paper author who needs a credible learned baseline, a team benchmarking a new descriptor against FPFH and Spin-Images, or a PhD student who wants a labeled 10,000-pair validation set tomorrow morning. Where it doesn't: anyone who needs alignment to work by Friday, anyone without GPUs, and anyone who reads "benchmark" and hears "product." The outputs are pairwise descriptor distances in a .log file and binary labels in .mat arrays. That is the deliverable.