Real-time ($\geq$ 30 fps), 1080p novel-view synthesis at state-of-the-art radiance-field quality — the first method to deliver both at the same time.

Until this paper the field had a hard trade-off. The quality leader, Mip-NeRF360, needed 48 h of training and rendered at 0.06 fps. The speed leaders, InstantNGP and Plenoxels, trained in minutes but rendered at 9–17 fps at visibly lower quality. This work reports 0.815 SSIM / 27.21 PSNR at 134 fps on the Mip-NeRF360 dataset after 41 min of training — matching or beating the 48-hour method while rendering roughly 2000$\times$ faster.

Three contributions get it there, and each is remarkable on its own:

1. Anisotropic 3D Gaussians as the scene representation. A primitive that is simultaneously a differentiable *volumetric* element (so it optimizes like a radiance field) and an *explicit, unstructured* one (so it rasterizes like a point cloud). No voxel grid, no hash table, no space compaction — and no wasted compute in empty space.

2. Optimization interleaved with adaptive density control. The set of Gaussians is not fixed: it is cloned, split and pruned during training based on the view-space positional gradient, so the representation grows exactly where the reconstruction is wrong. 1–5 million Gaussians covers every scene tested.

3. A visibility-aware differentiable tile rasterizer. Sorting is done once per frame with a single GPU radix sort over (tile, depth) keys instead of once per pixel, and the backward pass places no limit on how many splats receive gradients. The same kernel makes training fast *and* rendering real-time.

A fourth thing worth naming: there is no neural network anywhere in the pipeline. Geometry is explicit Gaussians, view-dependent color is spherical-harmonic coefficients, rendering is rasterization. The paper states outright that this contradicts the accepted wisdom that a continuous (implicit) representation is needed for quality.



Fig. 1 is the claim in one strip: same scene, same held-out view. InstantNGP reaches 22.1 PSNR at 9.2 fps, Mip-NeRF360 reaches 24.3 PSNR after 48 h at 0.071 fps, and this method reaches 23.6 PSNR in 6 minutes at 135 fps, or 25.2 PSNR in 51 minutes at 93 fps. The left half of the figure is the old trade-off; the right half is the point of the paper.

Every prior family of methods fails on one axis of the (quality, training time, render speed) triangle, and the failure is structural rather than an implementation detail.

NeRF-style implicit fields. Color along a ray is accumulated by volumetric ray-marching:

$$C = \sum_{i=1}^{N} T_i\,\bigl(1 - \exp(-\sigma_i \delta_i)\bigr)\,\mathbf{c}_i \quad\text{with}\quad T_i = \exp\!\left(-\sum_{j=1}^{i-1} \sigma_j \delta_j\right)$$

Because the field is continuous and implicitly encodes where matter is, the samples $i$ have to be found by stochastic sampling — expensive, and a source of noise. Quality-optimal Mip-NeRF360 pays 48 h of training and 10 s per frame for this.

Fast grid-based fields (InstantNGP, Plenoxels). These shrink or delete the MLP by storing features in voxel or hash grids. But they still ray-march, so many samples per ray are still required, and the accelerating grid is itself a structured prior: the paper notes they struggle to represent empty space and that image quality is limited by that grid.

Point-based rendering. Explicit and fast, but prior neural point methods depend on Multi-View Stereo geometry and therefore inherit its over- and under-reconstruction artifacts on featureless, shiny or thin regions, and their CNN rendering stage causes temporal flickering. Pulsar rasterizes fast but is order-independent and caps how many splats receive gradients.

The gap this creates. Nobody had an explicit representation that could be *optimized* as well as a volumetric one. That is the hole the paper walks into.

Input is exactly what a NeRF pipeline already needs: photos of a static scene plus SfM-calibrated cameras. The sparse point cloud SfM produces as a by-product — normally discarded — becomes the initialization.



Fig. 2 shows why the three contributions are one system rather than three tricks. The differentiable tile rasterizer sits on the *gradient* path (blue), not just the display path: it is what makes the projection, the Gaussian parameters and the density-control decisions all trainable from an image loss. Take it out and neither the optimization nor the real-time rendering survives.

Component 1 — the primitive. A 3D Gaussian with mean $\mu$ and full covariance $\Sigma$:

$$G(x) = e^{-\frac{1}{2}(x-\mu)^{T}\Sigma^{-1}(x-\mu)}$$

It projects to a 2D splat in camera space by $\Sigma' = J W \Sigma W^{T} J^{T}$, and $\Sigma$ is stored not directly but as a scale vector $s$ and a rotation quaternion $q$, so gradient descent can never produce an invalid (non positive semi-definite) covariance:

$$\Sigma = R S S^{T} R^{T}$$

Component 2 — optimization with adaptive density control. SGD on position, opacity $\alpha$, covariance and SH coefficients against

$$\mathcal{L} = (1-\lambda)\mathcal{L}_1 + \lambda \mathcal{L}_{\text{D-SSIM}}, \qquad \lambda = 0.2$$

every 100 iterations Gaussians whose view-space positional gradient exceeds $\tau_{\text{pos}} = 0.0002$ are cloned (if small: under-reconstruction) or split (if large: over-reconstruction), and near-transparent or oversized ones are pruned.

Component 3 — the tile rasterizer. Screen is cut into $16 \times 16$ tiles; Gaussians are frustum-culled at 99% confidence, duplicated once per overlapped tile, given a 64-bit key packing tile ID in the high bits and depth in the low bits, and sorted once by a single GPU radix sort. Each tile is then one thread block blending front-to-back out of shared memory until $\alpha$ saturates. The backward pass re-walks the same sorted lists back-to-front, so gradients reach an unbounded number of splats at constant per-pixel memory cost.

What it enables. Radiance fields stop being an offline format. A capture can be optimized in tens of minutes and then navigated interactively at 1080p in a real viewer (the authors built one on the open-source SIBR framework and measured their frame rates through it). Because the output is an unstructured set of explicit primitives in ordinary Euclidean space — no space warping, no compaction, no network weights — it drops into a conventional GPU rasterization pipeline rather than requiring a bespoke one.

The conceptual result. The paper's own framing is that it refutes a belief, not just a benchmark: a *continuous* representation is not strictly necessary for fast, high-quality radiance-field training. What volumetric rendering actually needed was differentiability and the ability to create/destroy/move matter — not continuity. 3D Gaussians supply both while remaining rasterizable.

Honest limitations the authors state. Artifacts in poorly observed regions; elongated or splotchy Gaussians; popping when large Gaussians switch blending order, caused by the guard-band culling and the approximate per-tile visibility ordering; no regularization at all; the position learning rate may need lowering for very large (urban) scenes; and peak training memory above 20 GB with several hundred MB per trained scene — far heavier than a NeRF's 8.6–48 MB.

Where the headroom is. About 80% of training time is still Python/PyTorch — only rasterization is CUDA. And the authors flag mesh reconstruction from the Gaussians as the interesting open question, since it would locate the method precisely on the continuum between volumetric and surface representations.

Worth stating plainly, because the paper sits in the middle of the NeRF literature and the name never appears in its own method:

- Geometry — an explicit list of 3D Gaussians ($\mu$, $\Sigma$, $\alpha$). Not an MLP, not a hash grid.
- View-dependent color — spherical-harmonic coefficients per Gaussian, 4 bands, introduced one band at a time during training. A closed-form basis, not a learned decoder.
- Rendering — $\alpha$-blending of sorted 2D splats. No CNN post-process, which is also why the result has none of the temporal flickering that CNN-based point renderers suffer.

So "training" here means gradient descent on a few million *primitive parameters*, not on network weights. That is why the method has no capacity ceiling to tune and uses one hyperparameter set for all 13 scenes.

Plenoxels also dropped the network, but kept a structured sparse voxel grid. Dropping both the network and the grid is what is new.

One held-out view of the Bicycle scene rendered five ways, with training time, PSNR and frame rate under each.

What to look at: the two "Ours" panels are the *same method at two stopping points*. At 6 minutes it already matches InstantNGP's best quality (23.6 vs 22.1 PSNR) at 135 fps against InstantNGP's 9.2. At 51 minutes it passes Mip-NeRF360's 48-hour result (25.2 vs 24.3) while still running at 93 fps against 0.071.

Why this matters for the Killer Application: it shows the method does not occupy a *point* on the quality/speed curve — it dominates the entire prior curve. A user picks a training budget and gets real-time rendering either way, which is precisely the choice that was unavailable before.

The paper is specific about the measurement setup, and the conditions are worth separating from the claim:

- Hardware: a single NVIDIA A6000 for every reported number except Mip-NeRF360's own published figures.
- Measurement path: frame rates were measured through the authors' interactive viewer built on SIBR, not from a synthetic benchmark loop.
- Resolution: native input resolution of each dataset was kept for all renders; the 1080p claim refers to that class of resolution.
- Scene cost: 411–734 MB of trained model plus 30–500 MB of rasterizer working memory, depending on scene size *and* image resolution.

Open questions the paper does not answer: how the frame rate scales on a consumer GPU with less bandwidth and VRAM; how it degrades as depth complexity rises, given that the rasterizer deliberately removes the cap on blended primitives per pixel; and whether the 16$\times$16 tile size is near-optimal or simply a workable default.

None of this undercuts the result — it bounds what "real-time" has been demonstrated *for*.

This is the hinge of the entire paper. Volumetric ray-marching in NeRF accumulates

$$C = \sum_{i=1}^{N} T_i\,\bigl(1 - \exp(-\sigma_i \delta_i)\bigr)\,\mathbf{c}_i, \qquad T_i = \exp\!\left(-\sum_{j=1}^{i-1}\sigma_j\delta_j\right)$$

which rewrites exactly as

$$C = \sum_{i=1}^{N} T_i\,\alpha_i\,\mathbf{c}_i, \qquad \alpha_i = 1 - \exp(-\sigma_i\delta_i),\quad T_i = \prod_{j=1}^{i-1}(1-\alpha_j)$$

while a neural point-based renderer blends the $\mathcal{N}$ ordered points overlapping a pixel as

$$C = \sum_{i \in \mathcal{N}} \mathbf{c}_i\,\alpha_i \prod_{j=1}^{i-1}(1-\alpha_j)$$

These are the same equation. What differs is only how the ordered list $\{i\}$ is obtained: NeRF must *search* for it by stochastic sampling of a continuous field; a splatting renderer already *has* it, because the primitives are explicit and can be sorted.

Everything else in the paper follows from taking that equivalence seriously — if the image formation model is identical, then the optimization quality of a volumetric method can be kept while paying only the rendering cost of a point method.

The fast NeRF variants (voxel grids, hash tables, codebooks, sparse octrees) all buy speed by storing interpolatable features in an accelerating data structure. The paper's diagnosis is that this creates two coupled ceilings:

1. Quality ceiling — the grid is a fixed, axis-aligned discretization. Scene detail that does not align with it costs cells, and empty space still consumes structure. The paper says image quality is limited in large part by the choice of grid.
2. Speed ceiling — the grid accelerates *lookup*, but the algorithm is still ray-marching, so many samples per ray must still be queried. Removing the MLP does not remove the sampling.

The 3D Gaussian representation escapes both because it is unstructured: primitives sit wherever the optimization puts them, at whatever anisotropic scale fits the local geometry, and empty space is represented by the absence of primitives rather than by empty cells. Density control (not resolution) is the knob.

Table 1 shows the price prior work pays for the structure: Plenoxels' voxel grid needs 2.1–2.7 GB per scene while reaching the lowest SSIM in the table.

The paper names Mip-NeRF360 as the current state of the art in novel-view-synthesis image quality and uses it as the quality benchmark throughout, adopting its dataset and its train/test protocol.

Its role in the argument is to define the number that had to be matched: 0.792 SSIM / 27.69 PSNR on its own dataset, at 48 h of training and 10 s per frame. The paper is careful about that 48 h — it was measured as 12 hours on a 4-GPU A100 node and reported as the single-GPU equivalent.

The paper also uses it as a *fairness* anchor: for Table 1 the authors copied Mip-NeRF360's published numbers on its own dataset rather than their own re-run, explicitly to avoid any confusion about what the current SOTA is, and put their own re-run in Appendix D instead.

No DOI or arXiv identifier is given in this paper's bibliography for this entry, so no link is attached here; the bibliography line is quoted verbatim below.

The two baselines that define the *fast* end of the trade-off, both cited by the paper as the methods whose training times it had to stay competitive with:

- InstantNGP [Müller et al. 2022] — multiresolution hash encoding plus an occupancy grid and a small MLP. In Table 1: 5m37s–7m30s training, 9.43–11.7 fps, 13–48 MB.
- Plenoxels [Fridovich-Keil and Yu et al. 2022] — a sparse voxel grid interpolating a continuous density field, with no neural network at all, using spherical harmonics for directional appearance. In Table 1: 25m49s training, 6.79 fps, 2.1 GB.

Both rely on spherical harmonics, and this paper follows that standard practice for its own color model — so SH is inherited, not claimed as a contribution. Plenoxels is also the precedent for "you can drop the network"; what remained to be dropped was the grid.

The link below is the DOI printed in this paper's own bibliography for the InstantNGP entry.

Prior neural point-based renderers take Multi-View Stereo geometry as input and therefore inherit MVS failure modes: over-reconstruction (invented geometry), under-reconstruction (holes) in featureless, shiny or thin regions. This method takes only the sparse SfM point cloud that camera calibration already produces for free.

The reason it can is that the primitives are not assumed to be surface samples. Earlier point methods modelled each point as a small planar disc with a normal — and normals are exactly what you cannot estimate reliably from extremely sparse SfM points. A 3D Gaussian with a full covariance needs no normal; adaptive density control then creates whatever geometry the sparse initialization is missing.

So the dependency is inverted: instead of needing good geometry to start, the method needs only a plausible *seed distribution*, and the optimization builds the rest. The Random Init ablation is the test of that claim — it degrades (mainly in the background, with unremovable floaters) but does not fail, and on the synthetic dataset with well-constrained cameras and no background it succeeds outright from 100K random points.

Open: how sparse can the seed get before density control cannot recover? The paper measures two points (SfM and uniform random) but does not sweep between them.

A Gaussian centered at mean $\mu$ with world-space covariance $\Sigma$:

$$G(x) = e^{-\frac{1}{2}(x-\mu)^{T}\,\Sigma^{-1}\,(x-\mu)}$$

multiplied by a learned opacity $\alpha$ during blending. To render, it is projected to camera space using the classic EWA splatting result:

$$\Sigma' = J\,W\,\Sigma\,W^{T}\,J^{T}$$

where $W$ is the viewing transform and $J$ the Jacobian of the affine approximation of the projective transform. Dropping the third row and column of $\Sigma'$ leaves a $2 \times 2$ matrix with the same structure as if one had started from planar points with normals — which is how a *volumetric* primitive becomes a 2D splat with no loss of machinery.



Fig. 3 makes the point that a rendered image cannot: the Gaussians are shrunk 60% so their shapes become visible. They are not blobs — they are long, thin, oriented ellipsoids that have aligned themselves with the slats of a vent. That alignment is the whole reason 1–5 million primitives suffice for a full unbounded scene: one anisotropic Gaussian can represent what would take many isotropic ones or many voxels, which is what keeps the representation both compact enough to fit in VRAM and small enough to sort every frame.

A covariance matrix is only physically meaningful if it is positive semi-definite, and plain gradient descent cannot be constrained to preserve that — a single update step can produce an invalid $\Sigma$. Optimizing the 6 free entries directly would break within a few iterations.

The fix is to never store $\Sigma$ at all. An ellipsoid is fully described by a scaling and a rotation, so the paper stores a 3-vector $s$ and a quaternion $q$, and composes

$$\Sigma = R S S^{T} R^{T}$$

with $R$ from the normalized $q$ and $S = \text{diag}(s)$. Any real $s$ and any unit $q$ yield a valid $\Sigma$ by construction, so the constraint is satisfied structurally rather than by penalty or projection. Activations reinforce this: sigmoid on $\alpha$ to hold it in $[0,1)$, exponential on scale.

One further decision matters for speed rather than correctness: the gradients for all parameters are derived explicitly (Appendix A) instead of relying on automatic differentiation, specifically to avoid autodiff overhead in the inner loop. Given that the rasterizer is the training bottleneck, hand-deriving $\partial\Sigma'/\partial s$ and $\partial\Sigma'/\partial q$ is part of why 30K iterations fit in ~40 minutes.

The number of Gaussians is not a hyperparameter — it is an output. Every 100 iterations (after warm-up), the optimizer looks at the average magnitude of view-space positional gradients and densifies wherever it exceeds $\tau_{\text{pos}} = 0.0002$:



- Top row, under-reconstruction — a small Gaussian sitting in a region with geometry it cannot cover. Response: clone it and displace the copy along the positional gradient. This *increases both* total volume and primitive count.
- Bottom row, over-reconstruction — one large Gaussian smeared across detail it cannot resolve. Response: split it into two, dividing scale by $\phi = 1.6$ and sampling the new positions using the original Gaussian as a PDF. This *conserves* volume while increasing count.

Pruning runs alongside: Gaussians below an opacity threshold $\epsilon_\alpha$, or too large in world space, or with too large a viewspace footprint, are removed.

Why this matters for the Killer Application: it is the mechanism that lets an *explicit* representation compete with a continuous one. A NeRF can put detail anywhere because it is a function over all space; a fixed point cloud cannot. Clone/split/prune gives the explicit representation the same freedom to create, move and destroy matter — which is exactly the property the paper identified as the real advantage of volumetric methods (see Eq. 1–3). Table 3 confirms it is load-bearing: disabling splitting costs $2.2$ dB.

The rendering algorithm, in the order it runs:

1. Tile — split the screen into $16 \times 16$ pixel tiles.
2. Cull — keep only Gaussians whose 99% confidence interval intersects the frustum, and trivially reject extreme ones with a guard band (projected 2D covariance is numerically unstable near the near plane).
3. Instantiate — duplicate each Gaussian once per tile it overlaps, assigning a 64-bit key: high bits = tile ID, low 32 bits = projected depth.
4. Sort — one single GPU radix sort over all instances. Because tile ID is in the high bits and depth in the low bits, this simultaneously groups by tile *and* orders by depth. Per-tile ranges are then found in parallel by comparing each key's high bits with its neighbours'.
5. Blend — one thread block per tile, collaboratively loading Gaussians into shared memory, accumulating front-to-back; a thread stops when its pixel's $\alpha$ saturates, and the whole tile terminates when all its pixels have.

The design decision worth naming: there is no per-pixel sorting and no per-pixel ordering pass. Prior $\alpha$-blending point renderers sorted per pixel, which is what made them slow. Blending here uses the single global sort, so it is *approximate* — but the paper argues (and measures) that the error vanishes as splats approach pixel size, and it is the only reason the same kernel can serve both a 30K-iteration training loop and a 134 fps viewer.

Duplicating Gaussians per overlapped tile does increase the work, but the paper's position is that this is amortized by simpler control flow and the high parallelism of an optimized GPU radix sort.

The rasterizer sorts splat *instances* once per frame by (tile, depth) and then blends every pixel in the tile in that one order. But the correct blending order is per-pixel: two splats can swap depth order across the width of a single 16-pixel tile, and a splat's depth key is its center's depth, not its depth at the pixel being shaded.

The paper's answer is explicitly an engineering trade, not a proof:

- the approximation becomes negligible as splats approach the size of individual pixels — and adaptive density control drives splats toward exactly that regime;
- no visible artifacts were found in *converged* scenes.

Both qualifiers matter. "Converged" excludes mid-training frames, and "approach pixel size" excludes the large Gaussians that survive in poorly observed regions — which is precisely where the paper reports its popping artifacts, attributed in part to Gaussians suddenly switching depth/blending order. So the known failure mode of the approximation is exactly the case its justification excludes.

The authors name antialiasing as the fix and leave it as future work. Open question: would a per-tile depth-range test, or splitting oversized splats at render time, remove popping without giving up the single-sort design?

It looks like a conflation: under-reconstruction (too little geometry) and over-reconstruction (one splat covering detail it cannot represent) are opposite defects, yet both are detected by the same test — a large average view-space positional gradient — and then separated only afterwards, by size.

The reasoning the paper gives is that the positional gradient measures neither "missing" nor "smeared" directly. It measures "the optimizer wants to move this primitive". In both defects the residual is large and moving the Gaussian would reduce it — the optimizer is trying to fix a representational shortfall with a translation it cannot express. So the gradient is a proxy for *the primitive is being asked to do something it cannot do*, which both cases satisfy.

The size test then picks the right remedy: small primitive means the geometry it should cover does not exist yet, so clone; large primitive means the geometry exists but is under-resolved, so split.

It is an elegant reduction — one cheap scalar already computed by backprop replaces any explicit reconstruction-error analysis. The remaining question is where it misfires: a Gaussian in a genuinely ambiguous region (specular, poorly observed) will also show a large positional gradient with no representational fix available, and densifying there is presumably one source of the elongated, splotchy artifacts the paper reports in its limitations.

The backward pass needs, for each pixel, the accumulated opacity at *every* step of the forward blend. The obvious implementation stores the per-pixel list of blended points in global memory — which is what prior work did, and which is impossible here because the whole point is that the list length is unbounded (see the 11 dB ablation).

The trick has two halves:

1. Re-traverse instead of store. The sorted array of Gaussians and the per-tile ranges from the forward pass are reused, walked back-to-front. Nothing per-pixel is written; the cost is a constant overhead per pixel. Each pixel additionally skips (expensive) overlap testing for any point deeper than the last point that actually contributed to its color.

2. Recover $T_i$ by division. Rather than a shrinking list of opacities, each point stores only the final accumulated opacity from the forward pass; dividing that by each point's own $\alpha$ during the back-to-front walk reconstructs the intermediate coefficient needed at that step.

The numerical cost is real and the paper handles it explicitly: repeated division is prone to instability (division by zero), so blending updates with $\alpha < \epsilon$ (with $\epsilon = \tfrac{1}{255}$) are skipped in *both* passes, $\alpha$ is clamped at 0.99 from above, and forward blending stops before accumulated opacity can exceed 0.9999.

This is the concrete mechanism behind "unbounded gradient depth complexity at constant memory" — the claim in the rasterizer node is only affordable because of this substitution.

Held-out test views, Bicycle / Garden / Stump, with ground truth at the left and non-obvious differences marked by red arrows and insets.

The differences are deliberately unspectacular, and that is the point of including them. In Bicycle the arrows sit on Mip-NeRF360 and Plenoxels, not on this method. In Garden the insets compare the fine table-edge and background detail. In Stump the contrast is vegetation: the paper notes that even Mip-NeRF360 retains blurriness in vegetation (Bicycle, Stump) and on the walls in Room that this method avoids.

Why it matters for the Killer Application: SSIM/PSNR/LPIPS could in principle be won by a smoother, blurrier reconstruction. Fig. 5 is the check that the metric wins in Table 1 come from *more* recovered detail rather than less — high-frequency vegetation and thin structure being exactly what an anisotropic primitive is supposed to capture and a grid method is supposed to lose. The metric table and this figure are making the same claim from two directions.

The authors also report that their method preserves visual detail of well-covered regions when viewed from a distance, which previous methods do not always do — a property visible only in the supplemental video paths, not in these stills.

What the evaluation does fix, credibly:

- Train/test split — every 8th photo held out, following Mip-NeRF360's own methodology, so the quality leader's protocol is used rather than a favourable one.
- One hyperparameter set across all 13 real scenes, which removes per-scene tuning as an explanation for the wins.
- Baselines re-run by the authors from the original code, at native input resolution, rather than quoted — except Mip-NeRF360 on its own dataset, where published numbers were copied deliberately to avoid disputing the SOTA, with the authors' own re-run disclosed separately in Appendix D.
- All test renders published on the project website for every method and scene.

What it does not control:

- Hardware parity for the 48 h claim — Mip-NeRF360 was trained on 4 A100s for 12 h and reported as 48 single-A6000-equivalent hours; the paper flags that A100s are faster than A6000s, so the conversion is an estimate.
- Metric choice — SSIM, PSNR and LPIPS disagree here (Ours-30K wins SSIM and LPIPS on the Mip-NeRF360 dataset but trails on PSNR, 27.21 vs 27.69). The paper's own qualitative figures argue the detail case that PSNR misses, but the disagreement is real and worth stating.
- Temporal quality — flicker and popping are the paper's known weaknesses and no still-frame metric measures them.

Ablations were also run on manually downsampled high-resolution inputs to avoid JPEG artifacts, so Table 3's absolute numbers are not directly comparable to Table 1's.

Only the rasterization routine is CUDA. Everything else — parameter updates, density control, the whole optimization loop — is PyTorch, and it accounts for roughly 80% of training time. The choice was deliberate: PyTorch to make the method easy for others to use.

The arithmetic is worth doing. If 80% of a 41-minute run is Python overhead, the CUDA-bound portion is around 8 minutes. Porting the optimization to CUDA the way InstantNGP did — which the authors explicitly name as the comparison — would attack that 80%, not the rasterizer.

This reframes the Table 1 training-time column. 41m33s is not this method's floor; it is its PyTorch prototype's floor. The 48-hour comparison against Mip-NeRF360 already holds with an unoptimized implementation, and the gap the paper reports is a lower bound on the gap the approach permits.

It also explains why the paper's speed claims sound stronger on the *rendering* side (134–197 fps) than the training side: rendering runs entirely through the CUDA path, training does not.

The single follow-up direction the paper singles out, and the framing is more interesting than the practical motivation.

The practical part is obvious: meshes are what every downstream tool — games, simulation, editing, physics — actually consumes, so a Gaussian scene that can be converted to one becomes usable outside a viewer.

The conceptual part is the authors' actual argument. This method's primitive is *neither* volumetric nor surface-based: it is a volumetric element that behaves enough like an oriented disc to be splatted, and Fig. 3 shows the optimization spontaneously flattening Gaussians onto surfaces without ever being told to. Whether a mesh can be recovered is therefore a diagnostic: it would reveal how far along the continuum from volume to surface these primitives have actually travelled.

Related open ends the paper leaves in the same region: antialiasing to fix popping, regularization for unobserved regions, point-cloud compression for the memory cost, and porting the remaining optimization to CUDA. The mesh question is the only one framed as understanding rather than engineering.

The paper publishes its source, all its data, and the real-time viewer used to measure the reported frame rates. The viewer is built on SIBR, the open-source image-based-rendering framework from the same lab, and the fast radix sort comes from NVIDIA's CUB routines.

The project site also hosts every test-view render used to compute the statistics in Table 1 — for this method *and* for all the baselines, on all scenes — plus the supplemental video paths that show the distant-view and temporal behaviour that stills cannot.

This matters for reading Table 1 sceptically: the frame rates were measured through a real interactive application rather than an offline timing loop, and the renders behind every number are inspectable rather than asserted.

Both links below are printed in the paper itself — the repository URL in §7.1 and the ACM DOI on the title page.