COOLJAPAN OÜ / Oxi3D
Oxi3D — point cloud processing

Twenty-two crates of point cloud. No C underneath.

A broad PCL and Open3D replacement in Rust — spatial search, filters, features, keypoints, registration, segmentation, surface reconstruction, GPU, WebAssembly, Python. Apache-2.0. Version 0.1.0 is not published yet, and the status section below says exactly why.

22 crates · 18 stable 1,137,964 lines Apache-2.0 wgpu + CubeCL wasm32 native
Dependency closure auditoxi3d · default build
ItemCountStatus
Boost0Absent
Eigen0Absent
FLANN0Absent
VTK0Absent
CMake / C toolchain0Absent
Rust code lines0All of it
PCL builds against Boost, Eigen, FLANN and VTK, and its GPU path is CUDA. Oxi3D's default build has none of them. The GPU backend is wgpu and CubeCL, so the same kernels target CUDA, Metal, Vulkan and WebGPU, and the whole workspace compiles to wasm32 without an Emscripten step. Nothing to install
Clause 01Selection

Two libraries own this field. Both are C++.

PCL and Open3D are the reason this field exists, and between them they define what a point cloud API looks like. They also define what it costs: a CMake build, a Boost dependency, a CUDA-only GPU path, and Python bindings that are either unmaintained or the whole reason the library exists.

LibraryLanguageGPU backendWebAssemblyPython
PCLC++14 / 17CUDA onlyNot supportedpython-pcl, unmaintained
Open3DC++14 + PythonCUDA onlyExperimentalFirst-class
Oxi3DRustwgpu + CubeCL — CUDA, Metal, Vulkan, WebGPUNative targetPyO3 with .pyi stubs

The GPU row is the one that changes what you can build. A CUDA-only backend decides your hardware vendor for you and rules out the browser entirely. The same Oxi3D kernels dispatch through wgpu and CubeCL, which is why there is a WebGPU path at all — see the status section for which of those backends has actually been run on metal.

Clause 02Scope

What is in the twenty-two crates.

Modular, not monolithic. Take the search layer alone, or the whole pipeline.

Search, filters, geometry
  • KdTree with SIMD and van Emde Boas layout
  • Octree, BallTree, R*-tree, HNSW
  • VoxelGrid, PassThrough, CropBox, SOR, ROR, MLS
  • Normal estimation, PCA, convex hull, OBB
  • RANSAC, MSAC, LMedS, MLESAC — nine geometric models
Features, registration, segmentation
  • FPFH, PFH, VFH, SHOT, ESF, CVFH, OUR-CVFH, spin image, NARF
  • ISS, Harris3D, SIFT3D, BRISK3D keypoints
  • ICP (point-to-point, point-to-plane, colored), GICP, NDT, SAC-IA, FGR, TEASER++
  • Euclidean cluster, region growing, DBSCAN, HDBSCAN, OPTICS
  • Plane, sphere and cylinder RANSAC
Surface, I/O, bindings
  • Poisson with V-cycle multigrid and Kazhdan-Hoppe screening
  • Marching cubes, ball pivoting, alpha shapes, TSDF
  • PCD, PLY, OBJ, STL, LAS/LAZ, E57, XYZ, ROS bag
  • PyO3 bindings with .pyi stubs; wasm-bindgen with WebGPU compute
  • ROS 2 PointCloud2 conversion and TF buffer
Clause 03Status

What is done, what is not, and what the README gets wrong.

This is a 0.1.0 that has not shipped. Everything below is a self-audit, which is worth exactly as much as self-audits usually are — which is why the audit itself is in the repository, per crate, rather than summarised here.

18 crates: core, io, search, filters, features, keypoints, registration, segmentation, surface, geometry, sample-consensus, gpu, viz, ml, python, ros2, wasm, facadeStable
4 crates: people, recognition, stereo, trackingExperimental
PCL feature parity, self-audited per crate≈ 85–90%
Open3D feature parity, self-audited per crate≈ 65–70%
cubecl-cuda GPU paths, run on an NVIDIA RTX A4000Verified on device
wgpu / WebGPU / Vulkan GPU pathUnverified
Python xyz_view() zero-copy NumPy viewImplemented
E57 writer — emits XYZ only, no intensity or colourLimited
Version 0.1.0 on crates.ioNot published
Published benchmark against PCL or Open3DDoes not exist

The repository README currently states the release shipped, carries a crates.io badge, links docs.rs and gives a cargo-add line. All of that is being corrected — 0.1.0 is not out. The same README quotes 2.5x, 5x and 3x ratios against PCL: those are target values written at the top of the benchmark file, not measured results, and where we have measured, the results are mixed. There is no speed claim anywhere on this page for that reason.

Clause 04Provenance

Nine years removing C. The point cloud engine is what got built on top.

Registration is optimisation. Feature descriptors are linear algebra. Surface reconstruction is a sparse solve. Every point cloud library in existence sits on Eigen, on FLANN, on BLAS — and all of it is C or C++, which is why installing PCL is a project in itself and why the GPU path has one vendor's name on it.

So the engine could not be written until the numerics were. We started at the bottom in 2017 and worked up: BLAS and LAPACK, then FFT, then the scientific core, then this. Oxi3D is not a port of PCL. It is the first thing that became possible once the floor underneath it was Rust.

Oxi3D 22 crates · point cloud, GPU, WASM, Python └─ SciRS2 numerical core — linalg, sparse, spatial, stats, cluster, optimize └─ OxiBLAS · OxiFFT linear algebra, transforms └─ Rust standard library. Nothing further down.

That order is the whole reason this repository is Apache-2.0 and the commercial products are not. Oxi3D is a floor, not a product. OxiCAD's B-Rep kernel sits on it; so does the medical imaging work. Giving away the floor and licensing what stands on it is the entire business model, stated plainly.

The stack is public on GitHub — 60+ projects, most of it Apache-2.0. Oxi3D is the part we give away.

Clause 05Next

Take it when it lands. Tell us what breaks before then.

The source will be published under Apache-2.0 at github.com/cool-japan/oxi3d. Until 0.1.0 is tagged, the useful thing you can send is the PCL or Open3D call you depend on that is not in the parity audit — those are what decide the release order. One line is enough.