Z-order Voxel Hashing in LiDAR Odometry
- Z-order voxel hashing is a spatial indexing technique that combines hierarchical voxel grids, Morton (Z-order) encoding, and open-addressing hash tables to enable O(1) correspondence queries.
- It eliminates runtime nearest-neighbor search and PCA by using pre-computed surfels stored in coarse voxels, significantly boosting real-time mapping performance.
- The method achieves transformative throughput with ~531 FPS on Livox AVIA, leveraging cache-efficient memory access and reliable planar mapping for LiDAR-inertial odometry.
Z-order voxel hashing is a spatial indexing technique employed in "Surfel-LIO: Fast LiDAR-Inertial Odometry with Pre-computed Surfels and Hierarchical Z-order Voxel Hashing" (Choi et al., 3 Dec 2025) to enable O(1) correspondence retrieval for real-time LiDAR-inertial odometry. This method integrates a hierarchical voxel structure with Morton (Z-order) curve encoding and open-addressing hash tables to achieve cache-efficient lookup and planar map representation. It eliminates runtime nearest-neighbor search and plane fitting by storing pre-computed surfel records per coarse voxel, significantly improving throughput without sacrificing accuracy.
1. Hierarchical Voxel Structure (hVox)
hVox adopts a two-level, axis-aligned voxel grid to organize spatial data. The first level (L0) consists of fine voxels of size ; each L0 cell holds an incremental centroid and point count, eschewing raw point storage. The second level (L1) comprises coarser voxels of size , where each L1 cell encapsulates a block of L0 children. Mapping between levels is performed via key transformation: given for L0, its parent L1 key is .
Updates to an L0 centroid mark the parent L1 surfel record as "dirty," triggering lazy recomputation at frame boundaries. Data representation per cell is as follows:
- L0[]: (point count and centroid)
- L1[]: (surfel normal, centroid, planarity)
This structure ensures efficient incremental map updates and rapid retrieval by localizing each query to a specific voxel, eliminating the need for extensive neighborhood enumeration.
2. Morton (Z-order) Curve Encoding
Spatial indexing uses Morton encoding to convert voxel coordinates into integer keys via bit-interleaving, thus mapping 3D locality into 1D address space. For quantized coordinates , , , each is represented in binary, and the Morton code is constructed as:
where are the th bits of respectively.
This encoding preserves spatial proximity: neighboring voxels produce numerically adjacent Morton codes, which is foundational for cache-friendly hash table accesses and systematic organization of map data.
3. Hash Table Lookup and Spatial Hashing
The Morton code serves as the key in an open-addressing hash table using Robin Hood hashing. The primary index is , where is the table size. Probes proceed as:
incrementing until the slot with matching key is found or an empty slot terminates search.
Average-case lookup is , markedly faster than nearest neighbor queries in tree or grid-based schemes, with the additional benefit that adjacent Morton codes, and by implication spatially close voxels, typically occupy neighboring hash slots, boosting cache hit rates. This enables high-throughput correspondence queries for each LiDAR point.
4. Pre-computed Surfels and Voxel Planarity
Each L1 voxel stores a surfel record derived from its occupied L0 children, obviating the need for runtime PCA. For centroids , the surfel parameters are computed as:
- Surfel centroid:
- Covariance:
- Eigen-decomposition with , and the normal vector (eigenvector of smallest eigenvalue)
- Planarity score:
At query time, the system retrieves only the pre-computed record from the hash table, bypassing PCA or neighbor assembly, ensuring minimal latency.
5. Performance Characteristics and Cache Locality
Each correspondence query comprises quantization (bit operations), Morton encoding, hash lookup, and surfel record access, all in constant time. Comparative experimental timings (per LiDAR point) show:
| Method | NN Search (μs) | Plane Fit (μs) |
|---|---|---|
| Fast-LIO2 (ikd-Tree) | ~1.4 | ~0.17 |
| Faster-LIO (iVox+PCA) | ~2.8 | ~0.61 |
| Surfel-LIO (hVox) | 0.05 | 0.01 |
Surfel-LIO achieves aggregate throughput of 531 FPS on M3DGR (Livox AVIA) versus 125 FPS (Fast-LIO2) and 184 FPS (Faster-LIO), while retaining state estimation accuracy. Cache locality is enhanced: adjacent LiDAR points, mapped to adjacent voxels, correspond to adjacent Morton codes and adjacent hash slots, promoting efficient memory access.
6. Single‐Point Correspondence Query (Pseudocode)
The following pseudocode exemplifies the lookup pipeline for a single LiDAR point:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
function findSurfel(p, s1, hashTable, rho_min):
# Quantize to L1 coordinates
kx, ky, kz = floor(p.x/s1), floor(p.y/s1), floor(p.z/s1)
# Compute Morton code
m = 0
for i in 0 .. N-1 do
xi = (kx >> i) & 1
yi = (ky >> i) & 1
zi = (kz >> i) & 1
m |= (xi << (3*i)) | (yi << (3*i+1)) | (zi << (3*i+2))
end for
# Hash-table lookup (Robin Hood)
entry = robinHoodLookup(hashTable, m)
if entry exists and entry.surfel.rho > rho_min then
return entry.surfel # {centroid c̄, normal n, planarity ρ}
else
return null # no valid correspondence
end if
end function |
7. Contextual Significance and Implications
Z-order voxel hashing with hierarchical surfel representation, as instantiated in Surfel-LIO, achieves constant-time correspondence retrieval for LiDAR-inertial odometry mapping. By leveraging Morton code spatial locality and deferred surfel recomputation, hVox enables transformative throughput while maintaining mapping fidelity in GPS-denied environments. A plausible implication is that similar architectures could extend to other large-scale mapping and real-time geometric perception domains, provided that spatial regularity and planarity assumptions are met. The employed design exemplifies an integration of spatial data structures and computational geometry with embedded system needs for real-time robotics and SLAM.