PointCNN: X-Conv, the TensorFlow 1.6 constraint, and what the repository actually gives you

The problem PointCNN addresses: convolution on unordered points

Images sit on a grid, so a convolution kernel has a fixed spatial relationship to its neighbours. Point clouds do not. A set of XYZ coordinates has no canonical ordering, and the same shape can be written as a different permutation of the same rows. Any operator applied to raw points must therefore either be invariant to that permutation or must first impose an order. PointCNN takes the second route. Instead of designing a hand-crafted invariant function, it learns a matrix, the X-transformation, that is applied to the input features and their associated coordinates before a standard convolution is applied. The README describes the project as "a simple and general framework for feature learning from point cloud", and the repository's stated results are the evidence it offers: 91.7% classification accuracy on ModelNet40 with 1024 input points only, 77.9% on ScanNet classification, 86.13% part-averaged IoU on ShapeNet Parts, 65.39% mean IoU on S3DIS, and 85.1% per-voxel labelling accuracy on ScanNet. The intended audience is researchers and engineers working on point cloud classification and segmentation, with the topics list naming autonomous driving, robotics and ScanNet. It is a reference implementation of a paper, not a packaged library.

X-Conv and X-DeConv: the two parameter lists that define the network

The architecture is not assembled from configuration files or a builder API. It is assembled from two Python lists of tuples, documented in the README against pointcnn_seg/shapenet_x8_2048_fps.py. Each entry in xconv_params is a tuple (K, D, P, C, links): K is the neighbourhood size, D is the dilation rate, P is the number of representative points in the output where -1 means every input point is retained, and C is the output channel count. The links field adds DenseNet-style skip connections, so an entry of [-1, -2] makes the current layer receive the outputs of the previous two layers. Stacking entries produces depth. The decoder side is described separately by xdconv_params, whose tuples are (K, D, pts_layer_idx, qrs_layer_idx). Here pts_layer_idx names which X-Conv layer output feeds this X-DeConv layer, and qrs_layer_idx names which X-Conv layer output is forwarded and fused with the result. The README notes that P and C for an X-DeConv layer are derived from qrs_layer_idx rather than stated directly. That is the whole data flow: a stack of X-Conv layers that progressively reduce and re-weight points, then a mirrored stack of X-DeConv layers that fuse encoder outputs back in through index references. If you want to change the network, you edit these tuples, and the indices in the decoder list must stay consistent with the encoder list or the graph will not build.

Getting it running: TensorFlow 1.6, Python 3, and the dataset scripts

The README states the code is implemented and tested with TensorFlow 1.6 in Python 3 scripts, and explicitly says TensorFlow before 1.5 is not recommended because of API differences. Dependencies named in the README are transforms3d, h5py and plyfile, with the caveat that more may be needed if the code complains. There is a documented workaround for Ubuntu 14.04 users stuck on TensorFlow 1.5: modify isnan() to std::nan() in /usr/local/lib/python3.5/dist-packages/tensorflow/include/tensorflow/core/framework/numeric_types.h at line 49. For ModelNet40 classification the README gives four commands: cd data_conversions, python3 ./download_datasets.py -d modelnet, cd ../pointcnn_cls, then ./train_val_modelnet.sh -g 0 -x modelnet_x3_l4. The -g flag selects the GPU and -x selects a hyperparameter set from the pointcnn_cls directory. ScanNet is not automated: you download the task data and scannet_labelmap from scan-net.org and the benchmark files from the ScanNet repository, arrange them as scannet_dataset_download with data, scannet_labelmap and benchmark subdirectories, move scannet_labelmap/scannet-labels.combined.tsv into the benchmark directory, then run python extract_scannet_objs.py -f ../../data/sc from data_conversions. The README's own listing is truncated mid-command, so the ScanNet path is the one to expect friction on. Pretrained models are offered through a OneDrive folder link, not a package index.

The real constraint is the TensorFlow generation, not the maths

PointCNN's limitation is not conceptual. It is that the repository targets TensorFlow 1.6, and the README's own workaround for an older OS shows how tightly the code is bound to that era's headers. Anyone arriving today with a current TensorFlow install will spend their first hours on environment archaeology rather than on point clouds, and the README does not provide a requirements file or a pinned environment. A second limitation is the configuration surface. Because the network is defined by index-linked tuples rather than a declarative schema, an off-by-one in qrs_layer_idx is not caught by a validator; it surfaces as a shape mismatch deep in graph construction. A third is scope. The repository covers classification and segmentation on ModelNet40, ScanNet, ShapeNet Parts and S3DIS. It does not present itself as a library with a stable API, a serving path, or a streaming inference story, so a team that needs to run this on live LiDAR frames is adapting research code, not integrating a component. The README also states the project prefers issues over emails for questions, which tells you the support model is community-driven and best-effort.

PointCNN++ and the other implementations: what to pick instead

The README's most useful paragraph is the first one. It announces PointCNN++ at github.com/ant-research/pointelligence, describing it as building on this work with "our latest architectural advancements, modernized codebase, and improved performance for point cloud processing", and it explicitly encourages researchers and developers to move there. That is the authors redirecting new work away from this repository, and it should carry weight in a build-versus-adopt decision. If you need PointCNN specifically but not the TensorFlow implementation, the README lists alternatives with genuinely different approaches: PyTorch Geometric's implementation, which puts the operator inside a general message-passing framework where you inherit its data loaders and batching; a PyTorch implementation from a Berkeley CS294-131 course project; an MXNet implementation at chinakook/PointCNN.MX; and a Jittor implementation inside Jittor/PointCloudLib. The practical difference is ecosystem, not accuracy. Choosing PyTorch Geometric means your point cloud pipeline shares types and utilities with the rest of a PyTorch codebase, at the cost of depending on that library's versioning. Choosing this repository means you get the authors' original X-Conv and PointCNN definitions in pointcnn.py, which is what you want if you are reading the paper alongside the code.

Licence status: MIT in the README, NOASSERTION in the metadata

The README states plainly that the code is released under the MIT License and points to the LICENSE file for details. The repository metadata supplied here reports NOASSERTION, which means the licence could not be identified automatically from the repository contents. Those two statements are not necessarily in conflict: NOASSERTION is a detection outcome, not a claim that no licence exists. But it is the kind of discrepancy that matters before you vendor code into a commercial product. The concrete step is to open the LICENSE file in your own checkout and confirm it contains MIT text with a copyright line, rather than relying on either the README sentence or the metadata field. This is not legal advice; if the code is going into a shipped product, the licence text is what your legal review needs to read. Note also that the pretrained models are distributed through a OneDrive link rather than the repository, so their terms are not covered by the LICENSE file at all.

Maintenance cost and what the repository expects from you

The last push to the default branch is dated 2026-03-12, but the only release listed is v1.0, tagged 2018-10-25 as the NIPS 2018 release. A repository whose sole tagged release is from 2018 and whose README now opens with a pointer to a successor is in maintenance-by-redirect mode. Practically, that means you should not expect the TensorFlow 1.6 dependency to be modernised here, and you should not expect the dataset download scripts to be kept in step with changes at scan-net.org or the ScanNet benchmark repository. The upgrade path the authors themselves propose is a different repository, not a version bump. Budget for the environment work as a fixed cost: a Python 3 environment with TensorFlow 1.6, transforms3d, h5py and plyfile, plus whatever else the code asks for at import time. If that environment cannot be built on your infrastructure, the decision is already made for you, and the PyTorch or Jittor implementations listed in the README are where the time goes instead.

Editorial conclusion

Adopt this repository if you need to reproduce the published PointCNN results or read the original X-Conv definition in the authors' own code, and you can supply a TensorFlow 1.6 environment in Python 3. Do not adopt it as the backbone of a new production pipeline: the README itself redirects new work to PointCNN++ at ant-research/pointelligence, and the code is written against a TensorFlow generation that is no longer the default install. Before committing, verify three things in your own checkout: that the LICENSE file actually contains MIT text, since the repository metadata reports NOASSERTION rather than a recognised licence, that data_conversions/download_datasets.py still resolves for the dataset you need, and that the pretrained model links still serve files. If any of those three fails, the cost of the reproduction is yours to absorb.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. yangyanli/PointCNN on GitHub