RadiusFPS: Dual Approaches in Robotics and Graphics
- RadiusFPS is a dual-use term describing an exact acceleration of farthest point sampling in robotic 3D perception via spherical voxel pruning and a retinal-based frame-rate mapping in foveated graphics.
- In robotics, RadiusFPS accelerates point cloud sampling with voxel-level pruning and coordinate skip tests, leading to significant speedups while preserving exact FPS output.
- In foveated graphics, it computes a radius-to-frame-rate mapping derived from an eccentricity-dependent flicker fusion model, optimizing rendering for gaze-contingent displays.
RadiusFPS denotes two distinct constructs in recent arXiv literature. In robotic 3D perception, it is the name of an exact acceleration framework for Farthest Point Sampling (FPS) based on spherical voxel pruning, with CPU and GPU realizations designed for latency- and memory-constrained point-cloud pipelines (Yu et al., 4 Jun 2026). In foveated graphics, the same label appears as a shorthand for a radius-to-frame-rate map derived from an eccentricity-dependent critical flicker fusion (CFF) model, used to choose a maximal imperceptible update rate as a function of retinal radius (Krajancich et al., 2021). The shared term therefore does not identify a single unified method; it names two unrelated techniques in separate subfields.
1. Nomenclature and scope
The 2026 usage is algorithmic and geometric. Given a point cloud and a desired sample size , classical FPS iteratively maintains the distance array , updates it against the most recently selected sample, and chooses the next sample by a global over . RadiusFPS preserves this standard FPS update rule under the same seed and tie-breaking policy, but accelerates the loop by pruning redundant distance computations through spherical voxel bounds and a coordinate-wise point-skip test (Yu et al., 4 Jun 2026).
The 2021 usage is perceptual and spatio-temporal. There, “RadiusFPS” is not presented as a standalone sampling algorithm; it is the step-by-step computation of a per-radius allowed frame-rate budget from the model , where is spatial frequency, is eccentricity, and is display luminance. The goal is to choose, for each retinal radius , a maximal frame rate no greater than the CFF for the highest spatial-frequency content present at that radius (Krajancich et al., 2021).
A common source of confusion is the acronym “FPS” itself. In the robotic-vision literature it denotes Farthest Point Sampling; in the foveated-graphics setting it denotes frames per second. The two RadiusFPS usages are therefore homonymous rather than methodologically connected.
2. RadiusFPS as exact acceleration of Farthest Point Sampling
In the robotic-vision formulation, classical FPS is motivated by its near-uniform coverage and its role in protecting geometric structure for downstream tasks such as LiDAR-based autonomous driving, SLAM, navigation, and segmentation. Its computational bottleneck is the 0 distance-update loop: each of the 1 iterations updates distances to all 2 points, which becomes dominant when modern sensors produce up to millions of points per second and 3 exceeds 4–5 (Yu et al., 4 Jun 2026).
RadiusFPS addresses this bottleneck by indexing the point cloud with active voxels. The axis-aligned bounding box of 6 is partitioned into cubic bins of side length
7
where 8, and similarly for the other axes. For each active voxel 9, the method stores its centroid 0, its minimal enclosing-sphere radius 1, the set of point indices 2, and the voxel-level maximum distance
3
The core FPS state remains
4
with the usual loop
5
The distinctive contribution is the conservative voxel-level pruning bound. For any 6 and newly selected sample 7,
8
Defining
9
RadiusFPS prunes the entire voxel whenever
0
Under that condition, no point in 1 can improve its stored nearest-sample distance, so the per-point Euclidean update is unnecessary (Yu et al., 4 Jun 2026).
Within non-pruned voxels, RadiusFPS applies a second filter: 2 If
3
then the Euclidean update is skipped for that point as well. Only the residual points require exact distance computation. This two-stage design is the basis for the reported average-case reduction from the full 4 work pattern, while worst-case complexity remains 5 when pruning fails (Yu et al., 4 Jun 2026).
3. Data structures, CPU realization, and GPU fusion kernels
The CPU formulation stores the points 6, the distance array 7, and an active voxel list 8, where each voxel keeps its point-index list 9, center 0, radius 1, and voxel-distance 2. The loop first builds active voxels by hashing each 3, initializes all 4 to 5, picks a random seed 6, computes initial distances, and initializes 7 by a per-voxel maximum over 8. Each subsequent iteration chooses the best voxel 9, the best point inside that voxel, adds the new sample, and then performs voxel-level pruning followed by point-level skip tests before recomputing the affected 0 values (Yu et al., 4 Jun 2026).
The GPU realization, RadiusFPS-G, keeps the entire pipeline on the GPU to avoid host–device synchronization. Preprocessing assigns a 1D voxel ID to each point, performs a parallel radix-sort by voxel ID so that each voxel’s points are contiguous, gathers them into SoA format for coalesced access, and computes per-voxel offsets and counts. Initialization then selects the seed 1, launches a branchless kernel to compute 2, and performs parallel reductions to set 3 (Yu et al., 4 Jun 2026).
Two fusion kernels organize the main loop. The first performs a two-level reduction: a warp-level reduction over 4 identifies the best voxel 5, then a block-level reduction over the points in 6 identifies the best point 7. The second maps one CUDA block to one active voxel, loads the new sample and voxel parameters into shared memory, computes the lower bound 8, exits early if the voxel is pruned, otherwise applies the coordinate-skip test and Euclidean update to the assigned points, and finally reduces within the block to refresh 9. The paper characterizes these kernels as fusing voxel selection, pruning, and distance update into memory-coalesced kernels and eliminating costly global-memory round-trips (Yu et al., 4 Jun 2026).
The theoretical guarantee is exactness rather than approximation. RadiusFPS preserves exact FPS output under the same seed and tie-breaking, and floating-point computations use the same precision and deterministic tie-breaking to guarantee reproducibility with classical FPS. This is significant because many FPS accelerations alter the selected subset; RadiusFPS is explicitly framed as a provably exact acceleration of the standard loop (Yu et al., 4 Jun 2026).
4. Empirical behavior, scaling, and operating regime
The 2026 evaluation uses S3DIS, ScanNet, and SemanticKITTI, with an Intel i7-12700KF CPU and an NVIDIA RTX 6000 Ada GPU. The reported metrics are sampling latency, end-to-end segmentation runtime, GPU memory, and segmentation accuracy measured by OA and mIoU. Baselines include CPU-FPS, GPU-FPS, QuickFPS, FPS+NPDU, and FastPoint (Yu et al., 4 Jun 2026).
The main reported outcomes are summarized below.
| Setting | Reported result | Context |
|---|---|---|
| CPU | up to 186× speedup over vanilla CPU-FPS | large scenes |
| GPU | up to 52× reduction in sampling time vs. GPU-FPS | RadiusFPS-G |
| Memory | 0 of QuickFPS GPU memory footprint | latency matches or outperforms QuickFPS |
| S3DIS | 40.18 s 1 15.34 s, mIoU 67.9% 2 68.3% | PointMetaBase / full validation |
| SemanticKITTI | 1734 s 3 691 s, 49.72% 4 49.26% | negligible accuracy loss |
| With FastPoint | sampling up to 11.7× faster, end-to-end 5 speedup, mIoU drop 6 pp | combined pipeline |
The paper also states that RadiusFPS-G sustains the highest throughput in Mpts/s across small to million-point scenes and maintains a moderate memory profile of about 7 MB, compared with about 8 MB for QuickFPS (Yu et al., 4 Jun 2026). This suggests that the method is intended not merely as a micro-optimization of the FPS kernel, but as a systems-level improvement for real-time robotic vision pipelines where both latency and memory pressure are first-order constraints.
The practical trade-off is the voxel resolution 9, or equivalently the voxel side length 0. A coarse grid reduces indexing overhead but weakens pruning; a fine grid tightens the geometric bound but increases voxel-management and cache overhead. The reported empirical sweet spot is 1–32 for typical indoor and outdoor scenes. The method can degenerate to classical FPS behavior when 2, when 3 is extremely large, when sample counts are very low, or for uniform spherical distributions that yield minimal pruning (Yu et al., 4 Jun 2026).
5. RadiusFPS as a radius-to-frame-rate map in foveated graphics
In the spatio-temporal foveation literature, RadiusFPS is the operational output of a perceptual model for eccentricity-dependent flicker fusion. The underlying model defines
4
the critical flicker fusion threshold as a function of spatial frequency 5, retinal eccentricity 6, and display luminance 7. At a reference luminance 8, with 9 trolands, the base model is
0
1
2
with fitted coefficients 3 reported for the relaxed fit and adjusted 4 (Krajancich et al., 2021).
Luminance dependence is incorporated via pupil diameter 5, retinal illuminance 6, and a Ferry–Porter gain: 7
8
with fitted parameters 9, 0, and 1. The model is based on measurements obtained with a custom near-eye DLP projector at 2 Hz, monocular green channel, peak luminance 3, using 2D Gabor wavelets at six spatial frequencies and eccentricities up to about 4, with nine subjects in a 2AFC QUEST protocol (Krajancich et al., 2021).
The RadiusFPS computation then proceeds from content to scheduling. For each pixel or patch at retinal radius 5, one decomposes the display content into spatial-frequency bands, computes the retinal eccentricity of each band relative to gaze, evaluates 6, and defines the per-radius allowed frame rate by
7
or, conservatively, by the highest-frequency band. The result is clamped to display limits and may be radially smoothed to avoid discontinuities. In a real-time pipeline, gaze from an eye tracker is converted to an eccentricity map, the CFF lookup produces a per-tile FPS budget, and rendering rate, shading rate, or frame insertion is adjusted per tile before compositing (Krajancich et al., 2021).
6. Validation, applications, and conceptual separation of the two usages
For the foveated-graphics RadiusFPS, validation is perceptual. A second user study with 8 presented video clips with flicker-modulated Gabor patches above and below model-predicted CFF, collected quality ratings on a 9–00 scale, and computed DMOS. The reported result is that only the RadiusFPS-based binary predictor, phrased as “flicker visible/invisible,” correlated highly with DMOS, with Pearson 01 and 02, whereas PSNR, SSIM, and VMAF failed to capture flicker thresholds. The associated bandwidth analysis states that spatial-only foveation yields compression gains of about 03–04 for typical VR fields of view, while spatio-temporal foveation using CFF provides an additional 05–06 saving, for a total of up to about 07–08 versus un-foveated and about 09–10 over spatial-only approaches (Krajancich et al., 2021).
Its listed applications are gaze-contingent rendering, video compression, and display hardware strategies such as dynamic backlight strobing and multi-rate scanning. Its limitations are equally explicit: the model targets binary CFF rather than a full spatio-temporal contrast sensitivity function, uses monocular fixed-fixation measurements, is measured only up to 11 cpd and extrapolated via a spatial-acuity model, assumes rotational symmetry and orientation-independence, and does not account for crowding, eye-motion blur, or chromatic channels (Krajancich et al., 2021).
For the point-cloud RadiusFPS, the applications are robotic perception pipelines that require high-quality FPS-style sampling under strict latency and memory budgets. Its limitations follow from the pruning mechanism rather than from perceptual modeling: worst-case time remains 12, pruning weakens under coarse voxelization or unfavorable distributions, and the choice of 13 determines the balance between tighter bounds and indexing overhead (Yu et al., 4 Jun 2026).
The two usages therefore occupy different conceptual roles. In one case, RadiusFPS is an exact geometric acceleration of an existing combinatorial sampling operator. In the other, it is a gaze-contingent frame-rate allocation derived from a psychophysical model. A plausible implication is that the shared name reflects the generic idea of mapping “radius” to an “FPS”-related quantity, but the underlying mathematics, implementation strategies, hardware assumptions, and evaluation protocols are entirely different.