torch-pointcloud: A timm-style Pretrained Model Library for 3D Point Clouds

When Point Clouds Meet timm: A Late but Necessary Standardization

Anyone who has done 3D point cloud research has probably had this experience: you want to run a PointNet++ baseline, so you go to GitHub to find the official implementation, only to discover that the dependent CUDA operators won't compile. You switch to a DGCNN implementation, but the interface is completely different. After finally getting it running, you try to compare results with those in someone else's paper and find that the evaluation strategies are entirely inconsistent.

A developer on Reddit (arthurdjn) spent several years of spare time building a project called torch-pointcloud to try to solve this problem. Its core idea is straightforward: just as timm does for image classification, unify multiple point cloud architectures and pretrained weights behind a single create_model() factory function.

The motivation behind this project isn't complicated — the author originally wanted to use torch-points3d, but there were too many installation errors, so they simply built a pure PyTorch implementation from scratch. The project is currently in alpha and is looking for early users and feedback.

Core Design: Reuse Rather Than Reinvent the Wheel

The most noteworthy design decision of torch-pointcloud is that core components like KNN, FPS (Farthest Point Sampling), and PointNetSetAbstraction have been given unified implementations, with all models sharing the same underlying interface. This means that PointNet++ and Point Transformer v3 are called in a consistent way:

import torch
import torch_pointcloud as tp

model = tp.create_model(
    "pointnext-sm.scanobjectnn-hardest.openpoints",
    task="classification",
    pretrained=True,
).eval()

pos = torch.randn(2048, 3)
x = torch.cat([pos, pos[:, 1:2] - pos[:, 1].min()], dim=1)  # xyz + height
batch = torch.zeros(2048, dtype=torch.long)
logits = model(x, pos, batch)  # (1, 15)

The benefits of this design are obvious. Over the past few years, core operators in the point cloud field have been reimplemented over and over again — every research group has its own KNN implementation, some using CUDA, some using pure Python, with varying performance and correctness. A unified implementation not only reduces bugs but also makes comparisons between different models fairer.

Regarding installation, the author took a pragmatic approach: rather than maintaining their own CUDA kernels, they try to reuse precompiled wheels already available in the community, such as those from PyG. pip install torch-pointcloud plus the corresponding pyg-lib is enough to complete the installation, which is much less of a barrier compared to compiling various custom operators from source.

KNN (K-Nearest Neighbors) is one of the most fundamental and frequently called operators in point cloud networks: given each point's feature vector, it finds the K nearest neighbors in feature space, which is used to construct local neighborhood graphs. PointNet++'s set abstraction, DGCNN's EdgeConv, and Point Transformer's attention computation all depend on it, but the definition of "distance" (Euclidean distance, feature-space distance, or a hybrid distance) and the batching approach vary widely across implementations, leading to inconsistent performance and numerical results.

FPS (Farthest Point Sampling) is the standard method for point cloud downsampling: each time it selects the point farthest from the already-selected set, thereby reducing the number of points from N to M while maintaining uniform spatial coverage. Compared to random sampling, FPS better preserves geometric structure, but its computational complexity is O(N·M), making it one of the performance bottlenecks for many segmentation and classification models. Having a unified implementation and reusing an optimized FPS is precisely the key to torch-pointcloud lowering the cost of reproduction.

Coverage: From PointNet to PointMamba

The range of architectures covered by this library is quite broad, and can be roughly divided into the following categories by task type:

Classification and Segmentation: PointNet++, DGCNN, KPConv, RandLA-Net, PointNeXt, PointMLP, Point Transformer v1/v2/v3, Sonata, PointMamba

Detection: VoteNet, 3DETR, PointPillars, SECOND, PointRCNN, SPVCNN, OctFormer

Self-supervised Pretraining: Point-MAE, Point-BERT, Point-GPT

Weights are hosted on Hugging Face, and dataset support covers mainstream benchmarks such as ModelNet40, ScanObjectNN, S3DIS, ScanNet, SemanticKITTI, nuScenes, KITTI, and SUN RGB-D. It also provides transforms, a tiled inferer for large-scale segmentation, and packed-batch tensor support following PyTorch Geometric conventions.

All checkpoints are named with a source-author identifier (such as .pointcept, .openpoints), and THIRD_PARTY_NOTICES.md lists the license and dataset terms for each source repository. This explicit attribution of sources is a responsible practice at a time when academia increasingly values reproducibility.

The point cloud tasks involved here can be understood as follows: classification assigns a single class label to the entire point cloud (such as the 40 object categories in ModelNet40); segmentation assigns a class to each point (such as indoor semantic segmentation in S3DIS); detection outputs 3D bounding boxes with class and orientation in a 3D scene (such as vehicles and pedestrians in KITTI and nuScenes); and self-supervised pretraining does not rely on manual annotations, instead using proxy tasks such as masked point modeling and contrastive learning to first learn representations on large-scale unlabeled point clouds and then transfer them to downstream tasks.

The datasets mentioned in the text also correspond to different levels of difficulty: ModelNet40 consists of clean synthetic CAD models; ScanObjectNN is built from real scans and includes occlusion and noise, making it more difficult; S3DIS and ScanNet are indoor scenes; SemanticKITTI, nuScenes, and KITTI are outdoor autonomous driving datasets. Weight name suffixes such as .openpoints and .pointcept indicate that the checkpoint comes from third-party codebases such as OpenPoints or Pointcept, making it easier to trace the source and license.

Why Reinvent This Wheel

The author explained their motivation in the post, and these reasons actually point to several structural problems in point cloud research.

Most point cloud libraries are built around research codebases, depend on config systems and custom operators, and require local compilation. More troublesome still, the code accompanying papers is often quietly changed after publication, making checkpoints impossible to reproduce. Evaluation strategies also differ across models — some use TTA, some use partitioning, and the results are not fair to compare side by side.

torch-pointcloud's approach is to re-benchmark all models under a unified strategy and compare them with the metrics reported in the original papers. This means that the reproduced metrics for some models may differ from the papers, but such differences are informative in themselves — they can help researchers distinguish between "improvements from the method itself" and "improvements brought by the evaluation strategy."

This is most valuable for researchers doing benchmark comparisons. If you have ever been unable to fairly compare two methods because different repos used different evaluation settings, the unified evaluation results provided by this library can serve as a reference baseline.

Current Status and Issues Worth Watching

The project is still in alpha, which means the API may still change and some model weights or features may be incomplete. The author also explicitly states that they are looking for early users and feedback.

For developers who want to try it, it is recommended to start with classification tasks (such as PointNeXt on ModelNet40 or ScanObjectNN), verify the installation and inference pipeline, and then gradually expand to segmentation or detection tasks. Detection models (such as VoteNet and PointPillars) are usually more sensitive to data preprocessing and coordinate system conventions, and may require more debugging.

Another thing to keep in mind is that although the library reuses precompiled wheels to simplify installation, dependencies such as pyg-lib are still tightly bound to PyTorch and CUDA versions. You need to confirm version compatibility before installation, otherwise you may encounter runtime errors.

The project's GitHub repository and documentation site are already online, and interested readers can get more detailed installation guides and tutorials there.

Additional Background

About PyG and packed batch: PyTorch Geometric (PyG) uses a "packed batch" to represent a batch of graphs or point clouds — concatenating the points and edges of multiple samples into one long tensor, then using a batch vector to record which sample each point belongs to, thereby avoiding the memory waste and useless computation caused by padding. torch-pointcloud follows this convention, which means it can directly plug into data loaders, sampling operators, and message passing layers in the PyG ecosystem.

About pyg-lib and precompiled wheels: pyg-lib is the low-level C++/CUDA extension of PyG, providing efficient implementations of KNN, radius search, FPS, and more. It releases corresponding precompiled wheels for PyTorch and CUDA versions, so during installation you must ensure that the torch version, CUDA version, and wheel tags match, otherwise symbol mismatches or direct import failures may occur. This is precisely the technical reason behind the warning in the article that "dependencies are tightly bound to PyTorch/CUDA."

One-line Summary

torch-pointcloud unifies point cloud models and evaluation behind a timm-style factory interface, aiming to solve reproducibility chaos.

Paragraph Summary

torch-pointcloud is a pure PyTorch point cloud library modeled after timm, built from scratch by its author due to frequent installation issues with torch-points3d. Through a unified create_model() factory function, it integrates classification, segmentation, detection, and self-supervised models such as PointNet++, DGCNN, Point Transformer v3, PointMamba, VoteNet, and Point-MAE under the same interface, and reuses low-level operators including KNN, FPS, and PointNetSetAbstraction. Weights are hosted on Hugging Face, and installation reuses PyG precompiled wheels as much as possible to avoid the CUDA compilation barrier. The project's most important claim is that all models are re-benchmarked under a unified evaluation strategy, thereby distinguishing improvements from the methods themselves from differences caused by evaluation settings. It is currently in alpha, and the author is looking for early users and feedback.