torch-points3d: a Hydra-configured harness for point cloud models on S3DIS and ScanNet

The problem: every point cloud paper ships its own training script

Point cloud research has a reproducibility problem that is structural rather than accidental. PointNet, PointNet++, RSConv, RandLA-Net, PointCNN, KPConv, MinkowskiEngine, VoteNet, FCGF, PointGroup, PPNet and PVCNN were each released with their own codebase, their own data loading, their own augmentation pipeline and their own evaluation script. Comparing two of them on S3DIS means reconciling two directory layouts, two sets of preprocessing assumptions and two metric implementations before you can trust the numbers. torch-points3d takes the position that the models are the interesting part and everything around them should be shared. The README describes it as a framework for running common deep learning models for point cloud analysis tasks against classic benchmark, built on PyTorch Geometric and Facebook Hydra. The intended user is a researcher or graduate student who needs to run an existing architecture on a standard dataset, or swap one module out and measure the difference, without rewriting the surrounding plumbing. It is explicitly not aimed at someone who wants a single pretrained model behind an HTTP endpoint.

How the framework is organised: datasets and models split by task

The repository layout is the clearest statement of the design. Under torch_points3d there are separate top-level directories for core, datasets, metrics, models, modules, utils and visualization. The datasets directory is then subdivided into segmentation, classification, registration, object_detection and panoptic, and the README states that each folder contains the dataset related to each task. Models follow the same split. This matters because it means a segmentation model and a registration model never share a config schema or a transform pipeline; they share only the lower-level modules and the training driver. The modules directory holds the reusable pieces, described in the README as basic modules that can be used in a modular way, which is where PointNet, KPConv, RSConv, RandLA-Net and the rest live. Around that sits conf, described as the home for all configurations for training and evaluation. Hydra reads from conf, so a training run is defined by composing config files rather than by editing Python. The outputs directory collects runs sorted by date, and benchmark holds output from benchmark runs. That separation is the actual mechanism: datasets produce samples, modules consume them, metrics score the output, and Hydra assembles the combination at launch time.

Getting it running: pip install, Docker, and the sparse convolution backend

The documented requirements are CUDA 10 or higher for GPU, Python 3.7 or higher with headers (python-dev), and PyTorch 1.8.1 or higher, with PyTorch 1.9 or above recommended. A sparse convolution backend is listed as optional, with a pointer to the repository's own installation instructions. The README recommends Docker for a more consistent setup, and gives this pull command: docker pull pytorch/pytorch:1.10.0-cuda11.3-cudnn8-devel. Once the environment exists, native or containerised, the install is a single line: pip install torch-points3d. Training is launched from the repository root through train.py, described as the main script to launch a training, and evaluation through eval.py. There are two supporting scripts worth knowing about: find_neighbour_dist.py, which the layout describes as a script to find the optimal number of neighbours within neighbour search operations, and the forward_scripts directory, which runs a forward pass on possibly non annotated data. That last one is the closest thing to an inference path in the repository. The conf directory is where you would look for the config keys that a given run needs; the README does not enumerate them, so the config files themselves are the documentation.

The dependency surface is the real cost, not the install command

The single pip install line understates what is happening. torch-points3d sits on top of PyTorch Geometric, which has its own compiled extensions, and on top of optional sparse convolution backends that are themselves CUDA extensions with their own build requirements. The README's own advice to use Docker, with a pinned image tag, is an admission that the native path is fragile. The version window is also narrow in practice: the stated floor is PyTorch 1.8.1, and the recommended Docker image ships PyTorch 1.10.0 with CUDA 11.3. If your cluster runs a newer CUDA toolkit, or if your organisation pins an older PyTorch, you are outside the combination the maintainers appear to have exercised. The release history reinforces this. The most recent release listed is 1.3.0 from April 2021, preceded by 1.2.0 in December 2020 and 1.1.1 in August 2020. The repository's last push is dated 2026, so there is activity on master, but the versioned releases are years behind it. Anyone who needs a pinned, versioned dependency should assume they are installing from the default branch or from a specific commit, and should test the full stack themselves rather than trusting that pip resolved something coherent.

Where it is the wrong tool: inference services and single-model deployments

If your goal is to run one point cloud model over incoming scans, torch-points3d is a poor fit. The repository is organised around training and benchmarking: train.py, eval.py, conf, outputs, benchmark. The one inference-shaped component is the forward_scripts directory, and the README describes it only as a script that runs a forward pass on possibly non annotated data. There is no mention of a serving layer, a model export path, a serialisation format or a batching API for production traffic. The dependency weight also cuts against deployment: you would be pulling PyTorch Geometric and a CUDA sparse convolution extension into a container to run a single architecture. A further limitation is task coverage within a given config. Because datasets and models are split by task, moving a model trained for segmentation onto a registration problem is not a config change; it is a different part of the tree. The framework's value comes from breadth across benchmarks, and breadth is exactly what you do not need when you have one model and one input format.

The alternative: PyTorch Geometric without the harness

The most direct alternative is PyTorch Geometric itself. torch-points3d relies on it heavily, and the README names it as one of the two foundations (the other being Hydra). The difference in approach is scope. PyTorch Geometric gives you the message passing primitives, the neighbourhood sampling and the data structures for irregular point sets, and leaves the training loop, the dataset splits, the metrics and the config system to you. torch-points3d supplies all of those, at the cost of a fixed directory layout and a Hydra configuration surface you have to learn. If you are implementing a new architecture and want maximum control over the training loop, PyTorch Geometric alone is less friction. If you are trying to reproduce a published number on S3DIS or ScanNet and do not want to reimplement the evaluation, the harness earns its weight. The honest framing is that torch-points3d is a convenience layer over PyTorch Geometric, not a replacement for it, and the convenience is real only when you are working on the benchmark tasks it already covers.

Licence and maintenance: what the repository does and does not tell you

The licence field for this repository is NOASSERTION, which means the automated classifier could not map the licence file to a known SPDX identifier. That is a signal to read the actual licence text in the repository before you depend on it, particularly if you plan to redistribute the code or ship it inside a product. Do not treat the absence of a recognised identifier as permission or as prohibition; it simply means the terms are not machine-classified. On maintenance, the facts available are limited. The last listed release is 1.3.0 from April 2021, while the default branch shows a push in 2026, so development has continued outside the release tags. The README links to a paper at 3DV describing the framework's capacities and benchmarks, and to a Slack channel, which suggests a research project maintained by its users rather than a commercially supported product. There is no documented deprecation policy and no stated support window. If you adopt it, pin a commit rather than tracking master, and budget for the possibility that an upstream PyTorch or CUDA change breaks the build with no tagged release to fall back to. I am not giving legal advice here; the licence file is the thing to read.

Editorial conclusion

Adopt torch-points3d if you need to run several published point cloud architectures against the same benchmark splits and want the dataset loading, metrics and training loop already wired together. Do not adopt it if you want a small dependency you can vendor into a production inference service, or if you cannot control your CUDA and PyTorch versions. Before committing, verify three things: that a sparse convolution backend (MinkowskiEngine, TorchSparse or the provided Docker image) builds against your CUDA, that the dataset you care about appears under torch_points3d/datasets in the task folder you need, and that a single config in conf/ actually trains end to end on your hardware, since the framework's value is entirely in that config-driven path.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. torch-points3d/torch-points3d on GitHub