---
title: 'RadiusFPS: Dual Approaches in Robotics and Graphics'
url: https://www.emergentmind.com/topics/radiusfps
type: topic
---

# RadiusFPS: Dual Approaches in Robotics and Graphics

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 [2606.06255]. 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 [2104.13514]. 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 \(P=\{p_0,\dots,p_{N-1}\}\subset\mathbb{R}^3\) and a desired sample size \(M\), classical FPS iteratively maintains the distance array \(D[i]\), updates it against the most recently selected sample, and chooses the next sample by a global \(\arg\max\) over \(D\). 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 [2606.06255].

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 \(CFF(f,e,L)\), where \(f\) is spatial frequency, \(e\) is eccentricity, and \(L\) is display luminance. The goal is to choose, for each retinal radius \(r\), a maximal frame rate no greater than the CFF for the highest spatial-frequency content present at that radius [2104.13514].

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 \(O(N\,M)\) distance-update loop: each of the \(M\) iterations updates distances to all \(N\) points, which becomes dominant when modern sensors produce up to millions of points per second and \(N\) exceeds \(50\mathrm{k}\)–\(100\mathrm{k}\) [2606.06255].

RadiusFPS addresses this bottleneck by indexing the point cloud with active voxels. The axis-aligned bounding box of \(P\) is partitioned into cubic bins of side length
\[
L=\frac{(1+\varepsilon)\max\{E_x,E_y,E_z\}}{n_{\mathrm{vox}}},
\]
where \(E_x=x_{\max}-x_{\min}\), and similarly for the other axes. For each active voxel \(v_k\), the method stores its centroid \(c_k\), its minimal enclosing-sphere radius \(r_k=\tfrac{\sqrt3}{2}L\), the set of point indices \(V_k\), and the voxel-level maximum distance
\[
D_v[k]=\max_{i\in V_k} D[i].
\]
The core FPS state remains
\[
D[i]=\min_{s\in S}\|p_i-s\|_2,
\]
with the usual loop
\[
D[i]\leftarrow \min\bigl(D[i],\,\|p_i-s_{j-1}\|_2\bigr), \qquad s_j=\arg\max_i D[i].
\]

The distinctive contribution is the conservative voxel-level pruning bound. For any \(p_i\in v_k\) and newly selected sample \(s\),
\[
\|p_i-s\|_2 \ge \|c_k-s\|_2-r_k.
\]
Defining
\[
LB(v_k,s)=\max\!\bigl(0,\|c_k-s\|_2-r_k\bigr),
\]
RadiusFPS prunes the entire voxel whenever
\[
LB(v_k,s)\ge D_v[k].
\]
Under that condition, no point in \(v_k\) can improve its stored nearest-sample distance, so the per-point Euclidean update is unnecessary [2606.06255].

Within non-pruned voxels, RadiusFPS applies a second filter:
\[
\|p_i-s\|_2 \ge \|p_i-s\|_\infty=\max_{a\in\{x,y,z\}}|p_i^a-s^a|.
\]
If
\[
\max_a |p_i^a-s^a|\ge D[i],
\]
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 \(O(N\,M)\) work pattern, while worst-case complexity remains \(O(N\,M)\) when pruning fails [2606.06255].

## 3. Data structures, CPU realization, and GPU fusion kernels

The CPU formulation stores the points \(P\), the distance array \(D\in\mathbb{R}^N\), and an active voxel list \(\{v_k\}_{k=0}^{K-1}\), where each voxel keeps its point-index list \(V_k\), center \(c_k\), radius \(r_k\), and voxel-distance \(D_v[k]\). The loop first builds active voxels by hashing each \(p_i\), initializes all \(D[i]\) to \(+\infty\), picks a random seed \(s\), computes initial distances, and initializes \(D_v[k]\) by a per-voxel maximum over \(D[i]\). Each subsequent iteration chooses the best voxel \(k^*=\arg\max_k D_v[k]\), 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 \(D_v[k]\) values [2606.06255].

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 \(s_0\), launches a branchless kernel to compute \(D[i]=\|p_i-s_0\|_2\), and performs parallel reductions to set \(D_v[k]\) [2606.06255].

Two fusion kernels organize the main loop. The first performs a two-level reduction: a warp-level reduction over \(D_v\) identifies the best voxel \(k^*\), then a block-level reduction over the points in \(V_{k^*}\) identifies the best point \(j^*\). The second maps one CUDA block to one active voxel, loads the new sample and voxel parameters into shared memory, computes the lower bound \(LB\), 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 \(D_v[k]\). The paper characterizes these kernels as fusing voxel selection, pruning, and distance update into memory-coalesced kernels and eliminating costly global-memory round-trips [2606.06255].

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 [2606.06255].

## 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 [2606.06255].

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 | \(\sim 50\%\) of QuickFPS GPU memory footprint | latency matches or outperforms QuickFPS |
| S3DIS | 40.18 s \(\rightarrow\) 15.34 s, mIoU 67.9% \(\rightarrow\) 68.3% | PointMetaBase / full validation |
| SemanticKITTI | 1734 s \(\rightarrow\) 691 s, 49.72% \(\rightarrow\) 49.26% | negligible accuracy loss |
| With FastPoint | sampling up to 11.7× faster, end-to-end \(\sim 3.3\times\) speedup, mIoU drop \(<2\) 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 \(40\) MB, compared with about \(80\) MB for QuickFPS [2606.06255]. 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 \(n_{\mathrm{vox}}\), or equivalently the voxel side length \(L\). 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 \(n_{\mathrm{vox}}\approx 24\)–32 for typical indoor and outdoor scenes. The method can degenerate to classical FPS behavior when \(L\to\infty\), when \(r_k\) is extremely large, when sample counts are very low, or for uniform spherical distributions that yield minimal pruning [2606.06255].

## 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
\[
CFF(f,e,L),
\]
the critical flicker fusion threshold as a function of spatial frequency \(f\), retinal eccentricity \(e\), and display luminance \(L\). At a reference luminance \(L_0\approx 380\ \mathrm{cd/m^2}\), with \(l_0\approx 1488\) trolands, the base model is
\[
\tau(f)=\max(0,\log_{10}f-\log_{10}f_0), \qquad f_0=0.0055\ \mathrm{cpd},
\]
\[
\zeta(f)=\exp(p_9\cdot \tau(f))-1,
\]
\[
CFF_0(f,e)=\max\!\Bigl(0,\,
p_0\tau(f)^2+p_1\tau(f)+p_2
+[p_3\tau(f)^2+p_4\tau(f)+p_5]\zeta(f)e
+[p_6\tau(f)^2+p_7\tau(f)+p_8]\zeta(f)e^2
\Bigr),
\]
with fitted coefficients \(p_0\ldots p_9\) reported for the relaxed fit and adjusted \(R^2\approx 0.94\) [2104.13514].

Luminance dependence is incorporated via pupil diameter \(d(L)\), retinal illuminance \(l(L)\), and a Ferry–Porter gain:
\[
CFF(f,e,L)=\bigl[1+s(e,f)\log_{10}\tfrac{l(L)}{l_0}\bigr]CFF_0(f,e),
\]
\[
s(e,f)=\zeta(f)(q_0e^2+q_1e)+q_2,
\]
with fitted parameters \(q_0=5.71\cdot 10^{-6}\), \(q_1=-1.78\cdot 10^{-4}\), and \(q_2=0.204\). The model is based on measurements obtained with a custom near-eye DLP projector at \(360\) Hz, monocular green channel, peak luminance \(380\ \mathrm{cd/m^2}\), using 2D Gabor wavelets at six spatial frequencies and eccentricities up to about \(57^\circ\), with nine subjects in a 2AFC QUEST protocol [2104.13514].

The RadiusFPS computation then proceeds from content to scheduling. For each pixel or patch at retinal radius \(r\), one decomposes the display content into spatial-frequency bands, computes the retinal eccentricity of each band relative to gaze, evaluates \(CFF(f,e,L)\), and defines the per-radius allowed frame rate by
\[
\mathrm{RadiusFPS}(r)=\min_{\text{bands at radius }r} CFF(f,e=r,L),
\]
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 [2104.13514].

## 6. Validation, applications, and conceptual separation of the two usages

For the foveated-graphics RadiusFPS, validation is perceptual. A second user study with \(N=18\) presented video clips with flicker-modulated Gabor patches above and below model-predicted CFF, collected quality ratings on a \(1\)–\(5\) 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 \(r\approx 0.99\) and \(p<0.001\), whereas PSNR, SSIM, and VMAF failed to capture flicker thresholds. The associated bandwidth analysis states that spatial-only foveation yields compression gains of about \(10\)–\(40\times\) for typical VR fields of view, while spatio-temporal foveation using CFF provides an additional \(2\)–\(7\times\) saving, for a total of up to about \(200\times\)–\(500\times\) versus un-foveated and about \(3\)–\(7\times\) over spatial-only approaches [2104.13514].

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 \(2\) 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 [2104.13514].

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 \(O(NM)\), pruning weakens under coarse voxelization or unfavorable distributions, and the choice of \(n_{\mathrm{vox}}\) determines the balance between tighter bounds and indexing overhead [2606.06255].

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.

Source: https://www.emergentmind.com/topics/radiusfps