Volume straight from the descriptor

Updated 2026-10-30 15:31; study: ~/code/data/meshes/fcp_3010_hull (sections/hull/README.txt).

Package v5.31 (commit db3e6ceb; the working tree only raises MAX_ATOMS), defaults (parts="tracked-fit", interp="poly", the gwn point slicer), 128 layers, 2048 atoms; the 12 objects of the collision section. The exact volume is the source mesh's (tetrahedra over its faces). From each mesh, 20k area-uniform surface points (seed 3) with the true normals; every point method gets the same points. FCP's volume is one contraction of the stored atoms: a ring's area is π Σ_k k (a_x,kb_y,k − b_x,ka_y,k) in its Fourier coefficients, and the height atoms are orthonormal on a part's layer centres, so the sum of the ring areas over the layers is the same expression in the atom vectors: V = dz · ∏scale · π Σ_parts sign · |Σ_k k (⟨a_x,k, b_y,k⟩ − ⟨b_x,k, a_y,k⟩)| (the midpoint rule over the layers; no ring is evaluated, no grid, no mesh; one numba loop). Standard route from points: screened Poisson reconstruction (Open3D 0.20, depth 8), then its mesh's volume, with the true normals (the best case) and with normals estimated from the points (what a scan gives). CPU: Intel i5-10400F; FCP's encode on numba's 12 threads and on a GTX 1650; Poisson on one thread (its threaded run was slower here). Times are medians over the objects.

Accuracy: FCP is within 0.74 % of the exact volume from the mesh (median 0.31 %) and within 1.76 % from the points (median 0.25 %), without normals; Poisson with the true normals is as close (median 0.22 %, max 0.90 %). With estimated normals Poisson is off by more than 5 % on 10 of 12 objects (bowl +152 %, bowl serving +145 %, mug +141 %, bowl dog +125 %, flower pot +109 %, mug ace +85 %, shoe +58 %, jogger +19 %, dino +6 %, spring -20 %): on the thin-walled ones the orientation flips across a wall and the surface closes over the opening (renders). More atoms, more layers: 6144 atoms at 128 layers and at 256 layers move the error little: from the mesh the median falls 0.31 → 0.17 → 0.13 % but the worst stays 0.71 %; from the points it is 0.25 / 0.28 / 0.24 %. The per-object errors keep their sign and size across the settings (mugs and bowls 0.2–0.7 % low, the spring from points 1.8 % high): a bias of the encoding and of the point slicer, not a shortage of atoms. The 6144-atom runs had other jobs on the machine (load average about 7, against about 0 for the 2048 run): their times in the first table are upper bounds. Time: once encoded, FCP's volume takes 20–57 µs, about the cost of the tetrahedron sum over the source mesh itself (27–235 µs, numba): faster on 9 of 12 objects, the gain growing with the mesh (spring, 77k faces: 5.1×); the volume of a Poisson mesh takes 3.3–12.7 ms (NumPy). The cost from points is the encode: 2.8 s on the CPU and 1.0 s on CUDA (median), against 1.5 s for Poisson on one thread; the descriptor, once made, also answers the other queries of this report. Caveats: clean, complete, uniformly sampled points; Poisson's meshes are not watertight by Open3D's strict test (the volume is taken as is, its sign ignored); learned reconstruction is not compared.