PointNeXt: the argument that PointNet++ was under-trained rather than under-designed

The paper's real claim is about your training loop, not its layer shapes

The title says it plainly: PointNeXt is a revisit of PointNet++, the 2017 hierarchical set abstraction network that a decade of point cloud work has been measured against. The abstract position, stated as a TL;DR in the repository, is that improved training and model scaling strategies boost PointNet++ to the state of the art, and that PointNet++ with the proposed model scaling becomes PointNeXt.

That framing matters because it is a deflationary claim. The paper is not introducing a new attention operator or a new sampling scheme. It is arguing that much of the accuracy gap reported between PointNet++ and its successors was attributable to how the baseline was trained, and that once the training recipe is fixed the older architecture closes a large part of the gap on its own. The model scaling is then presented as the remaining, smaller contribution.

The arXiv identifier is 2206.04670, and the venue is NeurIPS 2022. Code landed in June 2022 and the acceptance notice came that September, which is the usual cadence for a paper whose artifact and text shipped together.

Six authors are credited: Guocheng Qian, Yuchen Li, Houwen Peng, Jinjie Mai, Hasan Hammoud, Mohamed Elhoseiny and Bernard Ghanem. The repository carries 1076 stars and 163 forks with zero open issues at the time of writing, which is an unusually clean issue count for a research codebase of this age and mostly reflects where questions get asked rather than how few questions exist.

OpenPoints is the actual deliverable, and reproducibility is its pitch

The interesting engineering here is not the model. It is OpenPoints, the library the authors built around it, which the README calls a new and flexible codebase for point based methods. Four of its five stated features are about honesty in comparison rather than about capability.

Extensibility is the ordinary claim: the framework supports PointNet, DGCNN, DeepGCN, PointNet++, ASSANet, PointMLP and PointNeXt, and can be extended with graph convolutions, self attention, farthest point sampling and ball query. Reproducibility is the more specific one, meaning every implemented model is trained at least three times per task with mean and standard deviation reported in the paper, and with pretrained models and logs released. Fair benchmarking is the one that carries the paper's argument, since all models are retrained under the same improved strategies and are said to beat their originally published numbers.

That last point is the whole thesis turned into infrastructure. If the claim is that baselines were undertrained, then the evidence has to be baselines retrained by the people making the claim, not citations to other papers' numbers. A framework that makes that the default is doing methodological work that a single model release would not.

The fifth feature is convenience rather than virtue: models, optimizers, schedulers, loss functions and data loaders are all built from config files, and logging can be routed to wandb by setting `wandb.use_wandb=True` in the command. The repository structure supports the same story, with a tests/ directory, a cfgs/ tree, an openpoints/ submodule, a tools/ directory and a standalone examples/profile.py for measuring models.

Two install paths that do genuinely different jobs

The README splits installation in two, and the difference between them is larger than it first appears.

The pip route is one command:

pip install pointnext_official

What that buys you is metadata and checkpoint access. The package depends on openpoints as its core library, imports without compiling any CUDA extensions, and exposes a download helper:

pointnext-download --list
pointnext-download modelnet40-pointnext-s-c64 --output-dir ./hf_cache

The README is explicit that full training and evaluation still requires the custom CUDA and C++ ops, so reproducing benchmarks needs a source checkout instead. A second naming trap is worth knowing about: the PyPI name `pointnext` belongs to an unrelated project, which is why the official distribution is published as `pointnext_official`. Anyone following a tutorial from memory will type the wrong package name.

The source path is the one that runs experiments:

git clone --recurse-submodules https://github.com/guochengqian/PointNeXt.git
cd PointNeXt
git submodule update --init --recursive
source update.sh
source install.sh

The submodule commands are not optional. OpenPoints is a git submodule, so a plain shallow clone without `--recurse-submodules` gives you an empty directory where the library should be.

Checkpoints and large binaries have moved to Hugging Face Hub, while GitHub Releases and PyPI carry source and Python packages. The pyproject.toml declares `requires-python = ">=3.8"` and pins only floors for its dependencies: openpoints 0.1.2 or newer, huggingface_hub 0.19 or newer, and PyYAML 5.4 or newer.

Configuration files, not scripts, drive every experiment

The design decision that makes OpenPoints pleasant to work in is that experiments are data. A model is two lines of builder calls:

model = build_model_from_cfg(cfg.model)
criterion = build_criterion_from_cfg(cfg.criterion_args)

Everything else arrives through the same config object, which means switching architectures, tasks or optimizers means editing a YAML file under cfgs/ rather than editing Python. The README's example is the PointNet model config, and it shows how a classifier is assembled from an encoder and a head:

model:
  NAME: BaseCls
  encoder_args:
    NAME: PointNetEncoder
    in_channels: 4
  cls_args:
    NAME: ClsHead
    num_classes: 15
    in_channels: 1024
    mlps: [512,256]
    norm_args: 
      norm: 'bn1d'

Four input channels is the common point cloud encoding of xyz plus intensity or normals, and the 1024-wide bottleneck into a 15-class head matches a 15-class shape benchmark.

The uniform launch rule is a single line, with the task folder and config path substituted:

CUDA_VISIBLE_DEVICES=$GPUs python examples/$task_folder/main.py --cfg $cfg $kwargs

The examples/ directory is organised by task, with classification, segmentation, shapenetpart and profile.py as siblings. A segmentation run on S3DIS points at cfgs/s3dis/pointnext-s.yaml, and the README notes that most experiments there, along with ScanObjectNN and ModelNet40, ran on a single A100. Testing a specific fold passes `mode=test, --pretrained_path $pretrained_path` as the extra keyword arguments, so the same entry point covers training and evaluation.

The acknowledgements name PyTorch-image-models and mmcv as inspirations. That lineage shows: the config-driven build pattern, registry-style component naming, and the habit of one YAML file per model are all borrowed wholesale.

Blackwell support in v0.1.2 and the hardware floor it exposes

The release history is short and concentrated. All three tags landed within about a day in early July 2026: v0.1.0 and v0.1.1 first, then v0.1.2 the next day, which is the pattern of a maintainer finishing a packaging pass and then fixing the thing that packaging pass revealed.

v0.1.0 and v0.1.1 were plumbing. They introduced the helper package, the openpoints dependency, and checkpoint download helpers, and v0.1.1 expanded the FAQ coverage to include visualization, S3DIS folds, optimizer overrides, preprocessing, memory reduction, ShapeNetPart refinement and supported tasks.

v0.1.2 is the one with teeth. The release notes state that install.sh was rewritten around uv and Python 3.12 with PyTorch 2.7 built for CUDA 12.8, that `TORCH_CUDA_ARCH_LIST` now includes 12.0, and that this was verified end to end on an RTX 5090. In practice this sets a hardware floor for anyone building from source: Blackwell cards need CUDA 12.8 or newer and PyTorch 2.7 or newer, the legacy CUDA 11.3 recipe retained as a comment at the bottom of install.sh does not run on an RTX 5090, and the CUDA 12.x toolkits need a host compiler older than g++ 14, with gcc-13 and g++-13 named as a working pair. requirements.txt was relaxed at the same time to tolerate Python 3.10 to 3.12 and NumPy 2.x.

So the same repository serves two fairly different audiences. An older datacenter card still has a documented path, while anyone on consumer Blackwell needs the new recipe and a recent enough compiler. The last commit on the default branch is dated 2026-07-06, so the repository is being maintained rather than left to rot, though at the pace of a small number of targeted fixes rather than continuous development.

Where the repository stops and the external docs begin

The README is candid about being an entry point. Beyond the installation commands and the usage pattern, it defers detail to an online documentation site, a docs/ directory with mkdocs.yml and an mkdocs-material configuration, a model zoo hosted separately, and a checkpoints page. The checkpoints themselves sit on Hugging Face Hub with checksum manifests, a deliberate choice for files too large to live comfortably in a git repository.

The tree shows the shape of the effort. There are tests/ and tools/ directories, a notebooks/ directory for experimentation, a metadata/ directory that presumably feeds the release helpers, a pointnext_official/ package directory, and MANIFEST.in for packaging. The openpoints/ entry is the submodule, which is why the clone instructions insist on recursive submodules.

The one thing the repository does not settle is the paper's central quantitative claim, because that lives in the arXiv paper and its tables. The README asserts that the improved strategies lift all models and that pretrained models and logs are available, but the actual numbers, the per-task differences and the scaling behaviour live in the PDF. Readers who care about whether the argument holds up should treat the paper as the primary source and the repository as the reproduction path, which is the correct division of labour for a research artifact.

For practical purposes, the fastest route in is to install the pip package, list what checkpoints exist, pull the ModelNet40 classification config, and run a single-GPU training job on one task before committing to a full sweep across classification, segmentation and part segmentation.

Editorial conclusion

PointNeXt is worth reading as a piece of scientific criticism rather than as a new layer type. Its lasting contribution is the habit it forces: retrain the old baseline under a fair recipe before claiming a new architecture wins, and report the spread across repeated runs rather than a single number. The practical footprint today is OpenPoints, a config-driven PyTorch codebase with a ModelNet40 to S3DIS to ShapeNetPart task layout, checkpoints on Hugging Face Hub, and a source install path that only works when your CUDA toolkit matches your GPU generation. Start from a config file in cfgs/ rather than from a Python script, and treat the PyPI package as a metadata and checkpoint helper rather than a training environment.

Frequently asked questions

Official sources

1. guochengqian/PointNeXt on GitHub
2. License: MIT
3. Project website
4. README
5. Releases