LODGE: Level-of-Detail Large-Scale Gaussian Splatting with Efficient Rendering
Authors: Jonas Kulhanek
Marie-Julie Rakotosaona
Fabian Manhardt
Christina Tsalicoglou
Michael Niemeyer
Torsten Sattler
Songyou Peng
Federico Tombari
Venue: NeurIPS 2025 spotlight ()
Keywords: 3D Gaussian splatting
Level-of-Detail
Primary area: applications
TL;DR: LODGE delivers outstanding quality and superior rendering speeds in large-scale 3D scenes, enabling real-time rendering even on mobile devices.

Abstract: In this work, we present a novel level-of-detail (LOD) method for 3D Gaussian Splatting that enables real-time rendering of large-scale scenes on memory-constrained devices. Our approach introduces a hierarchical LOD representation that iteratively selects optimal subsets of Gaussians based on camera distance, thus largely reducing both rendering time and GPU memory usage. We construct each LOD level by applying a depth-aware 3D smoothing filter, followed by importance-based pruning and fine-tuning to maintain visual fidelity. To further reduce memory overhead, we partition the scene into spatial chunks and dynamically load only relevant Gaussians during rendering, employing an opacity-blending mechanism to avoid visual artifacts at chunk boundaries. Our method achieves state-of-the-art performance on both outdoor (Hierarchical 3DGS) and indoor (Zip-NeRF) datasets, delivering high-quality renderings with reduced latency and memory requirements.

LODGE: Level-of-Detail Large-Scale Gaussian Splatting with Efficient Rendering
Jonas Kulhanek 1.4, Marie-Julie Rakotosaona' Fabiin Manhardt', Christina Tsalicoglou', Michael Niemeyer', Torsten Sattler S Songyou Peng", Federico Tombari
1 Google, Google DeepMind, Technical University of Munich, Czech Technical University in Prague, Faculty Flectrical Engineering.
5 Czech Technical University in Prague, Czech Institute of Informatics, Robotics and Cyberneties
https://lodee gs.github...
Large-scale 3D reconstruction
State-of-the-art quality
Real-time rendering mobile devices
PSNR
257FPS
26.6
H30G5
41FPS
3005
ZipMeRS
43FPS
23.2
Scafoli-Gs
iPhone
40
150
260
Figure 1: LODGE. Applied to large-scale 3D scenes, LODGE achieves outstanding quality while maintaining superior rendering speeds. Furthermore, enables real-time rendering on mobile devices.
Abstract
this work, we present novel level-of-detail (LOD) method for 3D Gaus- sian Splatting that enables real-time rendering of large-scale scenes memory- constrained devices. Our approach introduces a hierarchical LOD representation that iteratively selects optimal subsets of Gaussians based camera distance, thus largely reducing both rendering time and GPU memory usage. We construct each LOD level by applying depth-aware 3D smoothing filter, followed by importance- based pruning and fine-tuning to maintain visual fidelity. To further reduce memory overhead, partition the scene into spatial chunks and dynamically load only relevant Gaussians during rendering, employing an opacity-blending mechanism to avoid visual artifacts chunk boundaries. Our method achieves state-of-the-art performance on both outdoor (Hierarchical 3DGS) and indoor (Zip-NeRF) datasets, delivering high-quality renderings with reduced latency and memory requirements.
Introduction
Novel view synthesis is central area of research in computer vision that enables applications in AR/VR, gaming, interactive maps, and others. The field has recently received lot attention with the advent of Neural Radiance Fields (NeRFs) [22] and 3D Gaussian Splatting (3DGS) [10] - the latter pushing the range of applications further as it enables real-time rendering. With the rising popularity of NeRFs and 3DGS, there is increasing interest in applying such methods to ever larger and more complex scenes [27, 11, 5). However, standard methods do not scale well to such large-scale environments [11, 18]. The core issue lies in the representation: to capture fine details,
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

Level
closest centers
Level 1
Level D
Chunk center
Chunk center
Full LOD representation
Chunk-based rendering opacity blending
Figure 2: Method overview. Left: The scene is represented with multiple LODs; 'active Gaussians' selected during training based camera distance. Right: We cluster cameras into chunks, pre-compute 'active Gaussians' per chunk, and render the two nearest chunks with 'opacity blending'.
high number of Gaussians is required. Consequently, even distant regions of the scene are populated with dense Gaussians representing fine-grained geometry, ie., elements that contribute little to the final rendered image. This leads to significant inefficiencies during rendering, as many far-away Gaussians are processed despite having minimal or no visible impact. Furthermore, memory limitations pose an additional challenge: not all Gaussians can fit into GPU memory simultancously, which is particularly problematic for mobile low-end devices where memory is severely constrained.
In computer graphics this problem has been extensively studied and ond-in in the context of mesh-based rendering effectively addressed using lfvel-of-detail (LOD) strategies. These techniques render lower-resolution versions of in- in-game assets when they are far from the camera and progressively replace them with higher-reoolution versions as the camera moves closer. While there are approaches that propose LOD for 3DGS large-scale scenes [18, 11, 29, 28], they primarily focus on improving rendering speed, without limiting the number of Gaussians loaded in GPU memory, making rendering on smaller devices a challenge. Such methods often require to recompute the subset of Gaussians that need to be rendered every new frame, adding overhead the rendering. More importantly. this requires all Gaussians from all different LODs (even more than 3DGS [10]) to be in GPU memory all time. Finally, existing LOD approaches [28, 29] require careful parameter tuning for each scene to achieve good quality and performance.
On the other hand, our method is designed to both improve the rendering speed for large-scale scenes and to limit the number of Gaussians needed in memory to enable applications on embedded devices. Similarly to existing LOD based methods, we represent the scene as multiple sets of Gaussians with varying level of detail. However, we propose to define regions space around a cluster center. Each region activates fixed set of Gaussians from the precomputed LODs to avoid overhead computation between different frames. Our contributions can be summarized as follows:
We propose novel LOD representation for 3DGS which, unlike previous methods [28, 29, 18], does not recompute the list of used Gaussians each frame and thus can be accelerated and compacted to allow rendering of large-scale scenes even on mobile devices.
We further design strategy to automatically select optimal hyperparameters for splitting LODs, whereas most other methods require hyperparameters to be tuned manually for each 3D scene.
To accelerate rendering further. we split the scene into chunks and pre-compute sets of active Gaussians per chunk.
Finally, we introduce a novel opacity interpolation scheme to produce visually pleasing rendering and remove any artifacts when transitioning between chunks.
We show that our method outperforms state-of-the-art (SOTA) approaches in terms of quality and rendering speed whilst reducing the number of Gaussians in memory.
Related Work
Novel view synthesis has received great attention recently, mainly thanks to the advent of neural radiance fields (NeRFs) [22] and later 3D Gaussian Splatting (3DGS) [10], which offered

---

par alternative with substantially faster rendering. Subsequently, 3DGS was further extended in many ways to handle antialiasing [37. 20, 31], to offer better geometry [38. 8]. or to accommodate different camera models [14, 35]. There has been a lot of effort on making 3D Gaussian Splatting representation smaller by compressing attributes of Gaussians [20, 3, 7, 24). Similarly to our approach, this also reduces the required memory and makes rendering faster. Other approaches modify the
rendering procedure to make rendering more efficient [21, 16, 12, 4, 36, 42]. Finally, a lot of interest has been directed towards optimizing scene representation from images captured under different time-of-day, seasons, or exposure levels [13, 25, 15, 39J. We consider these approaches orthogonal to ours they can also be applied top of our method. Similarly, some works [21, 17, 25] focused on removing the number of Gaussians by proposing alternative densification and pruning strategies [21, 17]. or by pruning Gaussians with little/no contribution to the rendering process [7, 3, 25] similar to our approach. While these methods make rendering efficient for small-scale scenes, very large scenes are still not tractable render in real-time without sacrificing quality.
Reconstructing large 3D scenes. When dealing with extremely large scenes that can span several city blocks, another line of works further proposed to split the scene into sub-regions, and reconstructing each one separatedly. First, as for NeRFs, [32, 33, 40J used per-region MLPs and special rendering procedures to better handle far-away regions. Later, similar techniques were also applied in the context of 3DGS [18, 6, 11, 19]. These methods can be used to train from large image collections efficiently. Our LOD representation can be built from an existing model and can thus be applied on top of these approaches. However, these approaches use a large number of Gaussians in GPU memory and cannot be rendered on low-end devices problem addressed by our method.
Level-of-detall 3DGS. The main contribution of our work is novel lfvel-of-detail (LOD) represen- tation. Nevertheless, we are not the first to propose incorporating LODs into 3DGS [29, 11, 23, 28, 18, 34J. While H3DGS [1I] and CLOG [23] build continuous multi-level representations, FLoD [29] and OctreeGS [28] use discrete levels, each being a set of Gaussians (similar to our approach). The authors start from a coarse set of Gaussians, which are then progressively densified to obtain the finer levels. Unlike them, our method builds a LOD structure on top of the standard reconstruction and can be applied to various existing methods while we observed that coarse-to- fine strategy tends to fail on large-scale scenes the densification fails when the coarse set is too sparse. Finally, all existing LOD methods [29, 11, 28, 23] dynamically select the set of 'active Gaussians' (Gaussians used in the rasterization) for each rendered frame. This leads slower rendering and requires all Gaussians to be loaded in GPU memory. Unlike them, our method splits the 3D scene into sub-regions and for each, it pre-select sets of 'active Gaussians', increasing rendering speed and lowering memory usage.
3 Method
Our method aims to make large-scale 3D Gaussian Splatting reconstruction render fast even on mobile devices. To this end, we introduce novel level-of-detall (LOD) representation and chunk-based caching scheme (see Fig. 2), leading to fast rendering whilst reducing the memory footprint.
Preliminaries: 3D Gaussian Splatting. 3D Gaussian Splatting [10] represents a 3D scene as set of Gaussian primitives, each having a mean (position) 14, covariance matrix Σ, opacity o, and view-dependent color. The Gaussians are splatted into 2D screen space (obtaining 2D means j²' and covariances E' [10, 43]), sorted in z-axis, and composited using alpha blending. The blending weight a for pixel of 2D Gaussian with mean n², covariance E', and opacity o is then given by the Gaussian function:
(I) Upon splatting of the 3D Gaussians, the 2D screen is split into tiles of 16 pixels each, with each 2D Gaussian being assigned to all (possibly many) tiles with which it overlaps. Subsequently, the Gaussians for each tile are then sorted and alpha blended in the rasterization process using Eq. (I).
a = =G(p))
G(p) = e (p--1))) (p-))")p-))))
Importance pruning. As part of our LOD representation, we adapt the importance pruning introduced in RadSplat [25]. During 3DGS training, many Gaussians can become less visible when their opacity decreases or when Gaussian in front of them becomes opaque. While 3DGS periodically removes Gaussians with low opacity, it does not remove occluded Gaussians (hidden behind other scene geometry). In RadSplar [25], the authors propose to measure each Gaussian's 's importance (importance score TV) by taking the maximum over the Gaussian's 's contribution (rendering weight in alpha blending) to any pixel in all training cameras. By removing all Gaussians with
Preliminaries:
3

---

importance score lower than some threshold, we can effectively prune Gaussians with very little impact on rendering. This makes rendering faster and also reduces memory, which particularly important when working with low-end devices. We follow [25] and prune twice during training.
Level of Detail (LOD) representation. We propose to represent 3D scenes as multiple sets of Gaussians that correspond to different levels of detail as visualized in Fig. 2. As motivated in the introduction, distant regions of the scene are often represented by large number of Gaussians that contribute little to the final rendering. Yet, these Gaussians still need to be evaluated by the renderer, causing excessive memory usage and computations. Individual pixels with a large number of visible Gaussians (Gaussians projected into them) can significantly slow down rendering due to how the pixels are processed in 16 16 patches. The main goal is, therefore, reduce the number of pixels with large number of visible Gaussians, as shown in Fig. 3.
Therefore, we propose represent faraway regions with less detailed sets of Gaussians and nearby regions with more detailed sets. To this end, we define multiple LOD levels: g(); L 1 > O, with (()) denoting the most detailed set, obtained by optimizing on the original set of images [10, 11]. We assume each LOD level (()) is constructed (as explained in the next section) such that a sufficient rendering quality is achieved when observed from distance of at least di. When rendering the LOD from a given camera pose, we select a subset of Gaussians from each LOD level (see Fig. 2). We call this set the 'active Gaussians', and for camera center c, it is defined as
(()) = U 1=0
{at go d S |1 cll2 < d
where do = 0, d2 oc, and μ is the mean of Gaussian from level L. As shown in Fig. 3, LOD rendering reduces long tail of the per-pixel visible Gaussians distribution accelerating the rendering.
Building LOD representation. We aim to construct each LOD level (()) such that sufficient rendering quality is achieved when observed from a distance of at least dj. To this end, we draw inspiration from the 3D filter proposed by MipSplatting [37]. As described there, while the rendered image is a 2D projection of a continuous 3D scene given by a set of Gaussians, the image itself is instead grid in which each pixel coordinate defines the sampling from the continuous 3D signal. For sampling interval of I in screen space, the pixel interval in 3D world space at depth d is T = 4. with f being the focal length. According to the Nyquist's 'ss theorem [26, 30, 37], components of the signal can only be reconstructed if they are sampled at invervals smaller than 2T'. Therefore, Gaussians smaller than 27 will only result in aliasing artifacts [37] and increase both memory usage and rendering time. To enforce Gaussians of size larger than 2T, we follow Mip-Splatting [37] and convolve each Gaussian with smoothing 3D filter. The resulting Gaussian function (for Gaussian with mean i and covariance E and for depth d) is given by
((x)=
x( (x- P(x-n)
Σ +
sd
where s is a hyperparameter.
To build the lower-detail representations g() that are viewed at distances larger than di, we copy Gaussians from (()) and add a smoothing 3D filter (Eq. (3)) for depth dj. While adding smoothing 3D filter alone does not directly lead to fewer Gaussians, a significant number of Gaussians will become redundant, reducing their contributions in alpha compositing. Eventually, using the impor- tance score from [25], we iteratively prune unused Gaussians. Note that we always employ a few fine-tuning steps to correct for errors introduced by pruning Gaussians. For the fine-tuning, we use LOD rendering with levels up to the currently optimized LOD level. More details in the supp. mat.
Selecting depth thresholds. An important question remains: how should the depth thresholds de be selected to maximize the rendering performance. The renderer operates on pixels grouped in 16 x 16 tiles and the rendering performance is heavily influenced by the number of Gaussians processed inside the same 16 x 16- 16-pixels tile. This is because all threads within a tile process the union of all visible Gaussians and must wait for the slowest thread to complete rasterizing. While is difficult to theoretically analyze the impact of thresholds on the number of processed Gaussians, we can estimate this number (cost) for different thresholds by rendering a subset of training views and choose the one that minimizes the average number of Gaussians per tile. In Fig. 4, we show the cost distribution

---

103
Full representation
L,D
number of
101
102
20-
in1-
10-
200
5000
1000
1200
number of visible Gaussians
d;
Figure 3: Visible Gaussians histogram. For each pixel we compute the number of visible Gaussians and show the histogram for base model 'Full representation" and LOD rendering 'LOO',
Figure 4: LOD threshold cost function. Visualized for 2 depth thresholds. Darker is lower cost.
for two LOD levels at depths dj and d2. Notice how the value of the minimum is similar for set {(x, aic,ar+b b) x E R.). This enables us to leverage simple greedy strategy starting at d1, iteratively adding more thresholds. This reduces the complexity of the search problem to linear one.
Reducing memory with chunk-based rendering. While LOD rendering (described far) makes rasterization fast by reducing the number of visible Gaussians, all Gaussians still need to be loaded in GPU memory. Moreover, the 'active Gaussians' need to be continuously recomputed, leading to overhead computations. This can be prohibitive for small devices where the amount of available memory is limited. To address this, we propose to split the scene into different regions called 'chunks' and store a fixed set of 'active Gaussians' per chunk. It is important to note that the set of 'active Gaussians' associated with a chunk is not merely a subset of all Gaussians located within its spatial boundaries (see Fig. 2. Instead, it represents the entire scene, with regions closer to the chunk center modeled at higher levels of detail. When rendering an image, the rasterizer simply uses the 'active Gaussians' pre-computed for the closest chunk.
To define the chunks, we split the scene by performing a K-means clustering on the training camera positions (more details in supp. mat.). For each chunk with center c, the 'active Gaussians' are defined by Eq. (2) computed at the chunk center (rather than the camera position), with depths di offset by the chunk radius (distance to next closest chunk center) to ensure sufficient resolution for all camera positions inside the chunk.
Visibility filtering. Given our LOD chunks, we further accelerate rendering by filtering the set of Gaussians for each LOD chunk. Following RadSplat [25] we additionally perform importance pruning for each LOD chunk, ie., we compute per-Gaussian importance scores and remove all Gaussians with importance score lower than fixed threshold. However, to further increase robustness, we add additional views by adding random perturbations to existing training views within the LOD chunk. To this end, we employ the original camera positions, but sample random orientations. Note, that if orientations were included alongside positions in defining LOD chunks, visibility filtering could achieve an additional reduction in the number of loaded Gaussians. Nonetheless, this gain would not be significant and would reduce the method's ' ability to handle rapid camera rotations and wide fields of view, both of which are common in practical applications (e.g. AR/VR).
Opacity blending for smooth cross-chunk transitions. Having constructed these chunks, a naive approach would be simply render the 'active Gaussians' for the chunk center. While this speeds up rendering and reduces memory, it also introduces sharp changes when rendering a dynamic video of a camera trajectory (see Fig. 7). These artifacts are inherently caused by an abrupt change in the "active Gaussians' while moving, without employing any form of smoothing filter during the transition. To resolve the issue, we propose smoothing strategy leveraging the two closest chunks (see Fig. 2). When rendering an image, we first seek the two closest chunk centers. We take their respective sets of active Gaussians and combine them. Afterwards, we modulate the opacity of Gaussians, which are not in the intersection of the two sets of active Gaussians, using
ū= (c (c- m.) (mmTTm(mm))))m m
a; aut
min(1, max (0,
m. my 11
where e the current camera position, my and m,, are the two closest chunk centers my being the chunk center to which Gaussian i belongs, and m, being the other chunk (not containing Gaussian i). Note that / the normalized length of the projection of (c - m.) onto the line connecting the two chunk centers. We use the length of projection instead of the Euclidean distance to achieve
5

---

SmallCity
Campus LPIPS
PSNR
SSIM
LPIPS
#G
FPS
PSNR
SSIM
#G
FPS
Zip-NeRF [2]
26.30 0.785 0.368
0.09
22.04
0.781
0.416
0.20
3DGS [10]
25.42 0.776 0.394
1375K
85.25
24.14
0.785
0.430
1142K
47.38
Mip-Splatting [37]
25.36 0.775 0.394
1445K
75.42
23.96
0.784
0.430
1188K
66.79
Scaffold-GS [20]
23.31 0.753
0.362
1347K
71.38
20.43
0.754
0.436
1335K
46.84
H3DGS [11]
26.42 0.807
0.331
7093K
38.07
24.60
0.798
0.396
6186K
34.32
FLOD [29]
24.82 0.758
0.429
497K
208.41
24.10
0.777
0.453
595K
120.61
OctreeGS [28]
25.98 0.807
0.326
1008K
120.27
25.22
0.800
0.408
642K
119.21
CityGS [18]
25.29
0.772
0.401
2615K
114.07
24.82
0.794
0.419
1881K
121.67
Ours
26.57
0.815
0.325
877K
257.46
24.75
0.803 0.394
1464K
218.96
Table 1: Hierarchical 3DGS comparison. We compare baselines on SmallCity and Campus scenes.
Ours achieves fastest rendering while outperforming others in terms of rendering quality. The first second, and third values are highlighted.
smooth transition even when the camera doesn't pass through the chunk center. Given the union of the two sets of active Gaussians with modified opacity, we proceed with the standard rasterization step. However, note that only the union of the two chunks needs to be loaded in memory and each rendering pass, we only need to update the opacity of the symmetric difference of the two active Gaussian sets.
In practice, reloading of LOD splits can be done in a background process that does not affect the renderer's runtime. We begin by loading the active Gaussians' properties (e.g., positions, colors) into GPU memory. As the camera moves, we only need to modulate the opacity of the two loaded chunks until the camera passes the center of the chunk. Then, we remove the Gaussians from the previous chunk, keep the ones from the closest one, and load Gaussians from the second closest chunk. The opacity blending at this point assigns weights close to 1 to all Gaussians from the closest chunk so there are no artifacts during loading the next chunk even if loading of the next chunk is delayed.
4 Experiments
To validate our method, we conduct experiments on large-scale indoor and outdoor datasets, com- paring our method to other SOTA approaches. We further analyze individual components of our method and evaluate rendering speed on various mobile devices. We report standard PSNR, SSIM, and LPIPS (VGG) metrics, but also FPS and the number of Gaussians loaded GPU memory (#G). The number of loaded Gaussians serves as a proxy for memory usage, offering a fairer comparison across 3DGS implementations (as opposed to peak- memory usage) as does not depend on the actual implementations but rather on the algorithm itself. For more details on implementation and the evaluation protocol, we kindly refer the reader to the supp. mat. All baselines and our method use a single NVIDIA A100 SXM4 40GB GPU for training and evaluation. For mobile experiments, used two iPhones (13 Mini and 15 Pro), as well as two lower-end laptops without a powerful GPU (MacBook Air M3 and HP Chromebook).
Datasets baselines. We use two larger-scale scale datasets to validate our approach, ie., two outdoor scenes from Hierarchical 3DGS dataset [11] and three indoor scenes from Zip-NeRF dataset [2]. Each scene consists of around 1000-2000 images. We compare our approach against the following baselines: Current SOTA on the Zip-NeRF dataset Zip-NeRF [2] slow to train and without real-time rendering. Traditional 3DGS basclines 3DGS [10], Mip-Splattngg [37], and Scaffold- GS [20]. LDD-based methods- H3DGS [11] (SOTA on the Hierarchical 3DGS dataset), FLOD [29], Octree-GS [28], and CityGS [18]. Note that H3DGS, Dctree-GS, FLOD were trained for 45K, 40K, and 100K iterations, while ours was trained for 36K iterations. For FLOD we use 3-4-5 LOD rendering and for H3DGS we employ their default T = 6. More details can be found in the supp. mat.
Evaluation on Hierarchical 3DGS dataset. As shown in Tab. 1, Zip-NeRR struggles on these large scenes, despite requiring much longer training (200K iterations vs. 36K for ours). This likely stems from its use of contiguous scene representation with limited resolution, unlike 3DGS,

---

H3DGS (II)
Octree-GS [28]
Ours
Ground truth
Campus
Figure 5: Hierarchical 3DGS qualitative results. We compare H3DGS [11] and Octree-GS [28] on
SmallCity and Campus scenes. We highlight close-up region (left) and far-away region (right).
which sparsely encodes only occupied space. Among non-LOD baselines, 3DGS [10] and Mip- Splatting [37] offer competitive quality and rendering speed, whereas Scaffold-GS [20] lags behind, likely due to suboptimal densification in large-scale scenes. H3DGS [1 attains high visual fidelity, but incurs significant overhead from per-frame LOD splitting and the large number of Gaussians, making it slower than other methods. FLOD fails to generate sufficient Gaussians due to their coarse-to- toesee-t--ine training scheme, discarding fine details early and struggling to recover them later, even though it uses three times more training iterations than related methods. Compared to Octree-GS [28] and CityGS [18], ours achieves higher overall quality while being twice as fast. Interestingly, both Octree-GS and CityGS excel on Campus in PSNR but underperform in SSIM and LPIPS. We attribute this to our method being more robust exposure variation but less effective in preserving perceptual similarity under appearance changes. In summary, our method consistently achieves the best results across all scenes whilst maintaining superior rendering efficiency. In qualitative comparisons (Fig. 5), we highlight close-up and distant regions to assess both local details and long-range fidelity. Overall, our method delivers sharper reconstructions in both close and distant regions. In contrast, Octree-GS appears blurrier nearby and suffers from color shifts at a distance, while H3DGS often exhibits jagged geometry, potentially due to its reliance on depth supervision.
Zip-NeRF dataset evaluation. As seen in Tab. 2, Zip-NeRF achieves the highest accuracy but requires long training (200K iterations) and does not support real-time rendering. We still include for reference. Among real-time-capable methods, our approach achieves the best trade-off between quality and speed. CityGS [18] slower than ours while also having worse quality. FLOD [29] renders fast but loses fine details due to early pruning in its coarse-to-fin -infine training. H3DGS [11] maintains high fidelity but significantly slower, requiring over 10M Gaussians and fer-frame LOD graph cuts. Octree-GS [28] offers good quality and decent speed, but is slower than ours due to per-frame MLP evaluations. Finally, Scaffold-GS [20] lags behind other non-L.OD baselines in both quality and speed. As for qualitative evaluation (Fig. 6), FLOD tends to produce blurrier results and often misses
7

---

FLOD (11]
Octree- GS [28]
Ours
Ground truth
Alameda
London
NYC
Figure 6: Zip-NeRF dataset qualitative comparison. On scenes: Alameda, London, NYC. We highlight close-up region (left) and far-away region (right).
Alameda SSIM
London SSIM
NYC SSIM
Method
PSNR
FPS
PSNR
FPS
PSNR
FPS
Zip-NeRF [2]
22.97
0.738
0.13
26.76
0.822
0.13
28.21
0.845
0.13
3DGS [10]
21.75
0.707
90.12
25.43
0.795
99.19
26.33
0.829
79.69
Mip-Splatting [37]
21.86
0.709
95.52
25.55
0.797
95.56
26.33
0.829
85.24
Scaffold-GS [20]
20.93
0.714
65.61
22.52
0.745
75.71
25.97
0.817
78.74
H3DGS [11]
22.21
0.739
27.82
26.34
0.823
30.49
27.28
0.849
33.11
FLOD [29]
21.35
0.666
276.52
24.38
0.753
195.06
25.01
0.781
260.85
OctreeGS [28]
22.94
0.734
119.83
26.04
0.817
153.06
27.05
0.839
146.29
CityGS [18]
22.43
0.729
174.07
25.87
0.809
190.10
26.55
0.839
144.91
Ours
22.41
0.741
229.99
26.34
0.818
252.58
27.40
0.849
280.22
Table Zip-NeRF dataset comparison. On scenes: Alameda, London, NYC. We report PSNR, SSIM, and FPS. The first
second. and third values are highlighted.
distant details (e.g., lamp in 2nd row). Octree-GS struggles with close-up sharpness (c.g., railing in 1 row) compared our method. For far regions, both methods perform similarly, though our model better preserves frebuerreyency highlights (e.g., London scene), while Octree-GS slightly reduces color artifacts under exposure variation due to its MLP-based design. In summary, our method can deliver sharper close-up reconstructions and comparable superior fidelity for far regions, while maintaining faster rendering speed.
In the Hierarchical 3DGS dataset [11], the camera follows linear trajectory with chunks aligned along it; therefore, only the two nearest chunks are relevant. Zip-NeRF [2], however, the chunks fully cover the scene and the camera may traverse diagonally, potentially being between three or

---

PSNR
Time
#Vis. G
#G
Full representation
26.62
15.17
925k
2639K
LOD (d=10)
26.45
5.61
324K
3465M
LOD (d=10,28)
26.50
4.75
209K
3815K
LOD (d=10,28,47)
26.46
4.17
182K
4016K
LOD (d=10,28,47,63)
26.50
4.07
172K
4145K
LOD (d=15,70)
26.55
5.24
267K
3377K
LOD (d=10,28) clusters
26.54
3.62
244K
795K
LOD (d=10,28) clusters + vis. filtering
26.55
3.15
185K
612K
Opacity blending
26.57
3.88
268K
877K
Table Performance analysis. We show impact of different number of LOD levels and impact of LOD clusters, visibility filtering, and opacity blending on rendering time and quality (PSNR). For LOD, we vary the number of levels and the depths d. Last three rows use chunk-based rendering.
Full
LOD
Chunk 2/1 second
Opacity blending
BET SALADINO at Jngas art du
BET SAL SALADIO
BET SALADINO
BET SALADINO Ingerare arr
closest
Figure 7: Ablation study. We compare the full representation (without LOD), full LOD, rendering from closest and second closest LOD chunks, and opacity blending.
more chunks raising the question of whether opacity blending of only two chunks is sufficient. Empirically, no artifacts were observed across Hierarchical 3DGS [11]. Zip-NeRF [2], and Mip- NeRF 360 [1]. We hypothesize that: Close to the training camera distribution, neighboring chunks are well constrained, producing near-identical renderings even without blending. b) Far from the distribution, viewpoints lie at chunk boundaries where only the two closest chunks dominate. Thus, two-chunk blending is generally sufficient.
Performance analysis & design validation. We conduct an ablation study the SmallCity scene assess the impact of key components of our method on rendering quality and speed. Quantitative results are shown in Tab. 3 (corresponding to SmallCity Tab. 1), reporting PSNR, render time, number of visible Gaussians, and memory usage. Time for reloading Gaussians at chunk boundaries excluded, is handled asynchronously. Qualitative results are shown in Fig. 7. We start with the base method ('Full representation") ), which includes importance pruning but no LOD. Adding to four LOD levels significantly improves rendering speed (up to 3x with just one level) a minimal cost in PSNR and sharpness due to more aggressive pruning. As additional levels yield diminishing returns, we decided to always employ two LODs for all experiments, as good speed and quality trade-off. Thresholds were selected automatically (Section 3, 'Selecting depth thresholds') ) and we show that when instead setting them manually (15 and 70 m), performance worsens compared to our automatic selection 'LOD (d=10,))).
The last three rows evaluate our chunk- based rendering. Clustering camera positions and adjusting depth thresholds by chunk radius improves quality ('LOD (d=10,28) + clusters') ), but increases Gaussian count due to finer LOD resolutions. Visibility filtering ('+ vis. filtering') further reduces both visible and loaded Gaussians, and thus rendering time. However, using the active Gaussians from only the chunk centers introduces visual artifacts at chunk boundaries, noticeable as sharpness discontinuities (Fig. 7, second column from right). To circumvent this issue, we introduce opacity blending between adjacent chunks (last row, corresponding to 'Ours' in Tab. 1), which smoothens transitions. While it slightly increases render time and Gaussian count, it runs faster and more memory- efficient than its non-chunk-basc L.OD counterpart, being particularly beneficial for memory- constrained mobile devices.

---

iPhone 13 Mini
iPhone 15 Pro
MacBook M3
Chromebook
HQ
FPS S. time
FPS S. time
FPS S. time
FPS
S. time
H3DGS
V
x
X
X
X
7
42
2
129
H3DGS r
V
X
X
13
19
5
97
3DGS
X
43
38
8
38
8
22
15
Full representation
V
26
18
29
19
17
31
Ours single cluster
42
34
5
41
7
23
10
Ours
35
5
43
22
Table 4: Mobile experiment. We estimate and compare the rendering speed (FPS) and sorting time in milliseconds (S. Time) various mobile devices. (X) means rendering crashed: HQ=high quality.
Rendering on mobile and low-power devices. Finally, we benchmark rendering speed on four devices: iPhone 13 Mini, iPhone 15 Pro, HP Elite Dragonfly Chromebook, and MacBook Air 13 inch, using the web-based 3DGS renderer by Mark Kellogg [9), which performs rendering with asynchronous Gaussian sorting running in parallel with the rasterization. We report both FPS (rasterization only) and sorting time (S. time) in milliseconds in Tab. 4. For H3DGS [11]. we show both the full model (r 0) and the default (7 6) configuration. Vanilla 3DGS renders fast due to its low Gaussian count but at the cost of poor quality (see Tab. 1; PSNR @ 25.42 vs. 26.57 for ours). H3DGS instead fails on iPhones due memory limitations and cannot render in real time on laptops. Notably, iPhone 13 Mini outperforms the 15 Pro in FPS due to its smaller display. Our method runs efficiently across all devices and achieves the best performance on laptops.
5
Conclusion
We introduced novel level-of-detail (LOD) approach for 3D Gaussian Splatting that enables real-time rendering of large-scale scenes, even on level LOD representation with chunk-based rendering to avoid per-frame overhead by precomputing active Gaussian sets for spatial regions. We further proposed an automatic threshold selection strategy and two-cluster opacity blending scheme ensure smooth transitions between chunks. Extensive experiments on both indoor and outdoor datasets demonstrate that our method outperforms state-of- the-art baselines in both rendering quality and speed. Importantly, our approach is deployable mobile devices, achieving real-time performance where other methods fail.
devices. Our method combines a multi-
Limitations. While our method enables real-time rendering mobile devices, it assumes that loading and reloading them when crossing chunk boundaries- practice, this would require optimized web servers and effective compression protocols to stream Gaussians to the device in real time, which we leave as future work.
be performed efficiently. In
References
[1] Jonathan T Barron. Ben Mildenhall, Dor Verbin, Pratul Srinivasan, and Peter Hedman. Mip-nerf 360: 360: Unbounded anti-aliased neural radiance fields. In CVPR, 2022.
[2] Jonathan T Barron, Ben Mildenhall, Dor Verbin, Pratul Srinivasan, and Peter Hedman. Zip-nerf: Anti-aliased grid-hased neural radiance fields. ICCV, pages 19697-19705, 2023.
[3] Zhiwen Fan, Kevin Wang. Kairun Wen, Zehao Zhu. Dejia Xu. Zhangyang Wang, et al. LightGaussian: Unbounded 3D Gaussian compression with 15x reduction and 200+ FPS. NeurIPS, 2024.
[4] Guofeng Feng, Siyan Chen, Rong Fu, Zimu Liao, Wang, Tao Liu, Zhilin Pei, Hengjie Li, Xingcheng Zhang, and Bo Dai. FlashGS: Efficient 3D Gaussian Splatting for large-scale and high-resolution rendering. arXiv. 2024.
[5] Tobias Fischer, Jonas Kulhanek, Samuel Rota Bulo, Lorenzo Porzi, Mare Pollefeys, and Peter Kontschieder. Dynamic 3D gaussian fields for urban areas. In NewrIPS, 2024.
10

---

[6] Yuanyuan Gao. Hao Li, Jiaqi Chen, Zhengyu Zou, Zhihang Zhong, Dingwen Zhang, Xiao Sun. and Junwei Han. CityGS-X: A scalable architecture for efficient and geometrically accurate large-scale scene reconstruction. arXiv, 2025.
[7] Sharath Girish, Kamal Gupta, and Abhinav Shrivastava. EAGLES: Efficient accelerated 3D Gaussians with lightweight encodings. In ECCV, 2024.
[8] Binbin Huang, Zehao Yu, Anpei Chen, Andreas Geiger, and Shenghua Gao. 2D gaussian splatting for geometrically accurate radiance fields. arXiv, 2024.
[9] Mark Kellogg- 3d gaussian splatting for three.js. GaussianSplats3D, 2025.
httra://ggthuub..oo//kkkeeee
[10] Bernhard Kerbl, Georgios Kopanas, Thomas Leimkühler, and George Drettakis. 3d gaussian splatting for real-time radiance field rendering. ACM TOG, 2023.
[11] Bernhard Kerbl, Andreas Meuleman, Georgios Kopanas, Michael Wimmer, Alexandre Lanvin, and George Drettakis. A hierarchical 3d gaussian representation for real-time rendering of very large datasets. ACM TOG, 43(4), July 2024.
[12] Dmytro Kotovenko, Olga Grebenkova, and Björn Ommer. EDGS: Eliminating densification for efficient convergence of 3DGS. arXiv, 2025.
[13] Jonas Kulhanek, Songyou Peng, Zuzana Kukelova, Mare Pollefeys, and Torsten Sattler. WildGaussians: 3D Gaussian Splatting in the wild. arXiv, 2024.
[14] Zimu Liao, Siyan Chen, Rong Fu, Yi Wang, Zhongling Su, Hao Luo, Li Ma, Linning Xu, Bo Dai, Hengjie et al. Fisheye-GS: Lightweight and extensible gaussian splatting module for fisheye cameras. orXiv, 2024.
[15] Jiaqi Lin, Zhihao Xiao Tang, Jianzhuang Liu, Shiyong Liu, Jiayue Liu, Yangdi Lu, Xiaofei Wu, Songcen Xu, Youliang Yan, and Wenming Yang. Vastgaussian; Vast gaussians for large scene reconstruction. In CVPR, 2024.
[16] Weikai Lin. Yu Feng. and Yuhao Zhu. MetaSapiens: Real-time neural rendering with efficiency-awand pruning and accelcrated foveated rendering. In International Conference on Architectural Support for Programming Languages and Operating Systems, 2025.
[17] Wenkai Liu, Tao Guan, Bin Zhu, Luoyuan Xu. Zikai Song, Dan Li, Yuesong Wang, and Wei Yang. EfficientGS: Streamlining Gaussian Splatting for large-scale high-resolution scene representation. IEEE MultiMedia, 2025.
[18] Yang Liu, Chuanchen Luo, Lue Fan, Naiyan Wang, Junran Peng, and Zhaoxiang Zhang. CityGaussian Real-time high-quality large-scale scene rendering with Gaussians. In ECCV, 2024.
[19] Yang Liu, Chuanchen Luo, Zhongkai Mao, Junran Peng, and Zhaoxiang Zhang. Citygaussian Efficient and geometrically accurate reconstruction for large-scale scenes. arXiv, 2024.
[20] Tao Lu, Mulin Yu, Linning Xu, Yuanbo Xiangli, Limin Wang, Dahua Lin, and Bo Dai. Scaffold-GS: Structured gaussians for view-adaptive rendering. arXiv, 2023.
[21] Saswat Subhajyoti Mallick, Rahul Goel, Bernhard Kerbl, Markus Steinberger, Francisco Vicente Carrasco, and Fernando De La Torre. Taming 3DGS: High-quality radiance fields with limited resources. In ACM TOG, 2024. doi: 10. 1011111//66828...0 36676944
[22] Ben Mildenhall, Pratul Srinivasan, Matthew Tancik, Jonathan Barron, Ravi Ramamoorthi, and Ren Ng. NeRF: Representing scenes as neural radiance fields for view synthesis. In ECCV, 2020.
Nguyen-Phuoe, [23] N Milef, D Seyb, T Keeler, T Nguyen- Phuoe, A Božič, S Kondguli, and C Marshall. Learning fast 3D
gaussian splatting rendering using continuous level of detail. In CGF, 2025.
[24] Simon Niedermayr, Josef Stumpfegger. and Rüdiger Westermann. Compressed 3D Gaussian Splatting for accelerated novel view synthesis. In CVPR, 2024.
[25] Michael Niemeyer, Fabian Manhardt, Marie-Julic Rakotosaona, Michael Oechsle, Daniel Duckworth, Rama Gosula, Keisuke Tateno, John Bates, Dominik Kaeser, and Federico Tombari. RadSplat: Radiance field-informed gaussian splatting for robust real-time rendering with 900+ FPS. arXiv, 2024.
[26] Harry Nyquist. Certain topics in telegraph transmission theory. Transactions of the American Institute of Electrical Engineers, 1928. doi: 10. AIEE,1998...... 1928.5055024.
11

---

[27] Konstantinos Rematas, Andrew Liu, Pratul P Srinivasan. Jonathan T Barron, Andrea Tagliasacchi, Thomas Funkhouser, and Vittorio Ferrari. Urban radiance fields. In CVPR, 2022.
[28] Kerui Ren, Lihan Jiang, Tao Lu, Mulin Yu, Linning Xu, Zhangkai Ni, and Bo Dai. Octree-GS: Towards consistent real-time rendering with LOD-structured 3D gaussians. arXiv, 2024.
[29] Yunji Seo, Young Sun Choi, Hyun Seung Son, and Youngjung Uh. FLoD: Integrating flexible level of detail into 3D gaussian splatting for customizable rendering. arXiv, 2024.
[30] Claude E Shannon. Communication in the presence of noise. Proceedings the
the IRF, 1949.
[31] Jianxiong Shen, Yue Qian, and Xiaohang Zhan. Gaussian soup. In CVPR, 2025.
LOD-GS: Achieving levels of detail using scalable
[32] Matthew Tancik, Vincent Casser, Xinchen Yan, Sabeek Pradhan, Ben Mildenhall, Pratul P Srinivasan, Jonathan T Barron, and Henrik Kretzschmar. Block-nerf: Scalable large seene neural view synthesis. In CVPR, pages 8258, 2022.
[33] Haithem Turki, Deva Ramanan, and Mahadev Satyanarayanan. Mega-NeRF: Scalable construction of large-scale nerfs for virtual fly-throuhhs. In CVPR, 2022.
[34] Zipeng Wang and Dan Xu. PyGS: Large-scale seene representation with pyramidal 3D Gaussian Splatting. arXiv, 2024.
[35] Qi Wu, Janick Martinez Esturo, Ashkan Mirzaei, Nicolas Moenne-Laccoz, and Zan Gojeic, 3DGUT: Enabling distorted cameras and secondary rays in Gaussian Splatting. arXiv, 2024.
[36] Vickie Ye, Ruilong Li, Justin Kerr, Matias Turkulainen, Brent Yi, Zhuoyang Pan, Otto Seiskari, Jianbo Ye, Jeffrey Hu, Matthew Tancik, al. gsplat: An open-source library for Gaussian splatting. JMI.R, 2025.
[37] Zehao Yu, Anpei Chen, Binbin Huang, Torsten Sattler, and Andreas Geiger. Mip-splatting: Alias-free 3d gaussian splatting. CVPR, 2024.
[38] Zehao Yu, Torsten Sattler, and Andreas Geiger. Gaussian opacity fields: Efficient high-quality compact surface reconstruction in unbounded scenes. arXiv, 2024.
[39] Dongbin Zhang, Chuming Wang. Weitao Wang, Peihao Li, Minghan Qin, and Haoqian Wang. Gaussian in the wild: 3D Gaussian Splatting unconstrained image collections. In ECCV, 2024.
[40] Guangyun Zhang, Chaozhong Xue, and Rongting Zhang. SuperNeRF: High-precision 3D reconstruction for large-scale scenes. IEEE TGRS, 2024.
[41] Richard Zhang, Phillip Isola, Alexei A Efros, Eli Shechtman, and Oliver Wang. The unreasonable effectiveness of deep features as perceptual metrie. In CVPR, 2018.
[42] Brent Zoomers, Maarten Wijnants, Ivan Molenacrs, Joni Vanherck, Jeroen Put, and Nick Michiels, PRoGS: Progressive rendering of Gaussian splats. In WACV, 2025.
[43] Matthias Zwicker, Hanspeter Plister, Jeroen Van Baar, and Markus Gross. Surface splatting. ACM TOG. 2001.
12

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification: The introduction states the claims made, including contributions made in the paper and important assumptions and limitations.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
is fine to include aspirational goals as motivation as long as is clear that these goals not attained by the paper.
2. Limitations
Question:
Does the paper discuss the limitations the work performed by the authors?
Answer: [Yes]
Justification:
Limitations discussed in 'Limitations' section in 'Conclusions'.
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create separate "Limitations" section their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect on the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't 't acknowledged judgment and recognize that individual actions in favor of transparency play impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
the paper. The authors should use their best
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [NA]
13

---

Justification:
The paper does not contain theoretical results.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated referenced in the statement of any theorems.
The proof' can either appear the main paper or the supplemental material, but they appear in the supplemental material, the authors are encouraged to provide short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should properly referenced.
4. Experimental result reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
Answer: [Yes]
Justification: The 'Method" and 'Experiments' section provide sufficient information to reproduce the main experimental results. Further details (such as exact values of hyperpa- rameters) are given in Supplementary Material.
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is novel architecture, describing the architecture fully might suffice, or if the contribution a specific model and empirical evaluation, it may be necessary either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of large language model), releasing of a model checkpoint, or other means that appropriate to the research performed.
While NeurlPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) If the contribution primarily new algorithm, the paper should make clear how reproduce that algorithm.
(b) If the contribution is primarily new model architecture, the paper should describe the architecture clearly and fully.
(c) If the contribution a new model (c.g.. a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome deseribe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should possible for other researchers to have some path to reproducing or verifying the results.
5. Open access to data and code
14

---

reproducible, they Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, as described in supplemental material?
Question:
Answer: [No]
Justification: Paper code cannot be released at the time of submission due to institutional policies.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurIPS code and data submission guidelines (uttps://nips.. cc/
for more details.
While we encourage the release of code and data, we understand that this might be possible, so "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https: / httppsscccppbpcccccceecce heabblicggiidee CodeeSbbm ssi aasonnooicyy for more details.
The authors should provide instructions data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. only subset of experiments should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended to the paper) recommended, but including URLs to data and code is permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
Justification: The full details are provided in Supplemental material.
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to a level of detail that is necessary appreciate the results and make sense of them.
The full details can provided either with the code, in appendix, or as supplemental material.
7. Experiment statistical significance
Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Answer: [No]
Justification: Due to a restricted computational budget, we weren't able to compute error bars.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by error bars, confi- dence intervals, or statistical significance tests, least for the experiments that support the main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall with given experimental conditions).
15

---

The method for calculating the error bars should be explained (closed form formula, call a library function, bootstrap, etc.)
The assumptions made should be given (e.g., Normally distributed errors).
It should be clear whether the error bar is the standard deviation the standard error of the mean.
It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful figures symmetric error bars that would yield results that are out of range (e.g. negative rates).
show in tables or
If error bars are reported in tables or plots, The authors should explain the text how they were calculated and reference the corresponding figures tables in the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the puter resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?
Question:
Answer: [Yes]
Justification:
The details are given in the 'Experiments' section.
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs as well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary failed experiments that didn't 't make it into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurlPS Code of Ethics https http://nenii..p.eeeee wwterrissccpppulule Souublic/Ethcssuiddeee
Answer: [Yes]
Justification: The paper fully conforms to the code of ethics.
Guidelines:
The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special cireumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g., if there is special consid- cration due to laws or regulations in their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification: We aren't aware of any potential misuse of our method. We discuss societal impact in Supplementary Material.
Guidelines:
The answer NA means that there is no societal impact of the work performed.
If the authors answer NA or No, they should explain why their work has no societal impact why the paper does not address societal impact.
16

---

Examples of negative societal impacts include potential malicious unintended uses (e.g., disinformation, generating fake profiles, surveillance), faireess considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional unintentional) misuse of the technology.
If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification:
The paper does not pose risk of misuse.
Guidelines:
The answer NA means that the paper poses no such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Are the creators or original owners of assets (e.g.. code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Question:
Answer: [Yes]
Justification: The datasets citations and credit the authors.
released part of papers. We include appropriate
Guidelines:
The answer NA means that the paper does use existing assets.
The authors should cite the original paper that produced the code package or dataset.
The authors should state which version of the asset is used and, if possible, include URL.
The name of the license (e.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (e.g., website), the copyright and terms of service of that source should be provided.
17

---

If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswi thcode. com datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.
If this information not available online, the authors are encouraged to reach out to the asset's s creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [NA]
Justification: The paper does not release any assets alongside the paper submission.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/moodl as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent obtained from people whose asset used.
At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsoureing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well details about compensation (if any)?
Answer: [NA]
Justification:
The paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included in the main paper.
According to the NeurIPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or equivalent approval/review based the requirements of your country institution) were obtained?
Answer: [NA]
Justification: The paper does not involve crowdsoureing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing research with human subjects.
Depending the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
18

---

We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors adhere the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Does the paper describe the usage of LLMs if it is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, formatting purposes and does not impact the core methodology, scientific rigorousness, or originality of the research, declaration is not required.
Question:
Answer: [NA]
Justification: The core method development in this research did involve LLMs as any important, original, or non-standard components.
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, non-standard components.
Please refer to our LLM policy btopp::/nnerips... for what should or should not be described.
19

---

A Supplementary Material
A.1 Video
In the attached video
gg..gg...... g.ggthbb....... 1o/video.html we present a qualitative comparison between our method and several existing approaches. First, we compare our method with ZipNeRF [2], Octree-GS [28]. H3DGS [11], and 3DGS [10] on the SmallCity and Campus scenes from the Hierarchical 3DGS dataset [11], as well as the NYC and London scenes from the ZipNeRF dataset [2]. ZipNeRF produces less sharp results, particularly for nearby cars and the ground. Octree- GS exhibits over-exposure and reduced detail in close-up cars. H3DGS achieves comparable visual quality to ours but is significantly slower to render. 3DGS, on the other hand, suffers from blurriness and noticeable loss of detail. Next, we demonstrate how our LOD representation effectively reduces the number of visible Gaussians, thereby accelerating the rendering process. Finally, we show temporal artifacts when using 'LOD + chunks' (without opacity blending), and show how opacity blending removes these artifacts.
A.2 Implementational Details
In our method, we first optimize the 'base' model ie., a vanilla 3DGS reconstruction and then build the LOD representation on top. Given the 'base' model, we build the LOD representation (as described Section 'L.OD structure optimization steps'). We then build the LOD chunks as described in Section 3 of the main paper. In Section 'Selecting chunk centers' we give details on how the chunks are selected. To build the 'base" 3DGS reconstruction, we combine several improvements from recent literature [37, 11, 25] which we describe in Section 'Detailed on training the full representation'.
LOD structure optimization steps. In this section we detail the exact steps and parameters used for creating the LOD gaussians. Given a sequence of depth thresholds d,, we build the LOD sets (()) from the finest to the coarsest level. We start from the set g(0), iteratively adding more levels. At step I, we construct the set g()) via applying a 3D smoothing filter to all Gaussians in g(o), Note that the smoothing filter is only added to the Gaussian function, whereas the parameters remain unchanged. Therefore, the optimization process cannot decrease Gaussians' sizes below the 3D filter size. Next. we prune all Gaussians in g()) using the importance score pruning and then perform 100 optimization steps. The optimization steps use the LOD rendering procedure (with LOD levels up to 1) described in the previous section, with the modification that depth di is replaced by a random number drawn from a uniform distribution ((0.7d,, 1.3d.). This makes the representation more robust towards cameras lying outside of the training trajectory. We use the same loss function (DSSIM+LI) as during the standard optimization, however, we only update parameters of the Gaussians in set Gj. This process of pruning and fine-tuning is repeated in total three times, with importance score thresholds of 0.2y, 0.6y, and 7, where 7 is a hyperparameter. Therefore, we need overall Nivvls 3 I 000 optimization iterations.
Selecting chunk centers. We split the scene into chunks, by performing a K-means clustering on the training camera positions. We set the number of clusters Nelusters as follows:
N.
4 d1
c= 1 N
Nelusters
max ||c: - ell:
cj
(5)
where No is the number of training cameras, G are camera positions, and d1 is first LOD depth threshold. For outdoor scenes this roughly corresponds (empirically) to cluster sizes of 5 meters.
Details on training the full representation. In our method, the LOD representation is build from an existing 3DGS representation. To this end, we extended vanilla 3DGS with recent improvements [37, 11, 25] to achieve better quality of the base representation. We employ the original 3DGS renderer augmented with a 2D filter, as proposed in Mip- Apl-ttpatting [37]. However, for densification, we adopt the modified strategy from H3DGS [11]. Specifically, replace the original hard threshold on the 2D position gradient norm used for cloning/splitingg with the condition:
grad_position_22 _D_ max_radii _i__radd__222 _idii_2D__a (opacity) 1/5 >= threshold,
(6)
where max Lax_radii_2000 2iliii22iiii is the largest. radius the Gaussian projects into (since the last densification). Moreover, instead of averaging the gradient statistics, we take the maximum. We use gradient
20

---

threshold of 0.015 for the Hierarchical 3DGS [11] dataset and 0.03 for the ZipNeRF [2] dataset. All models were trained for for 30 000 iterations. We reset opacity every 000 steps until iteration 15 000 and apply densification every 300 steps from step 600 to 15 000. Importance score pruning is performed at steps 000, 16 000, and 24 000 with threshold of 0.02 for all scenes, except Campus, where we use lower threshold of 0.01.
A.3 Datasets
To validate our method, we use two larger-scale datasets: two outdoor scenes used in the Hierarchical 3DGS paper [11] and three indoor scenes from the Zip-NeRF paper [2].
Hierarchical 3DGS dataset [11].. The public release of the dataset contains two urban scenes (SmallCity and Campus). To collect the dataset, authors used bicycle helmet which they mounted 6 GoPro HERO6 Black cameras (5 for the Campus scene). The SmallCity scene was collected by riding a bicycle at around 6 7km/h, while Campus was captured on foot wearing the helmet. Poses were estimated using COLMAP with custom parameters and hierarchical mapper. Additinal per-chunk bundle adjustment was performed, see Hierarchical 3DGS [11]. In our experiments, we use the official train/test split provided by the authors. We also use the official segmentation masks provided with the dataset to remove license plates, pedestrians, and moving cars.
Zip-NeRF dataset [2].. The dataset contains four large-scale indoor scenes seenes: Berlin, Alameda, London, and NYC, (1000-2000 photos each) captured using fisheye cameras. We use the provided undistorted images and following Zip-NeRF [2). we use downscale factor of two resulting in down- sampled resolutions between 1 1392 793 and 2000 x 140 depending on scene. Note, that use the provided downscaled JPEG images for training and evaluation. In our experiments, we only use Alameda, London, and NYC, because for some baselines the Berlin scene cannot be fitted into GPU memory. Same as Zip-NeRI, we take each 8th image as testing image (when sorted alphabetically).
A.4 Evaluation Protocol & Baselines
We report standard PSNR, SSIM, and LPIPS metrics. To ensure a fair evaluation and reproducibility, before computing metrics, we round the predictions to uint8 range. For the Hierarchical 3DGS dataset, we mask the prediction and the ground truth image by the provided mask replacing the pixels inside the mask with black color. For SSIM, we use commonly used default values and average across pixels and color channels. For LPIPS [41], we use the VGG network (unlike some baselines which used AlexNet with lower values). To compute FPS, we compute rendering times for each testing image. We compute each per-image rendering time 7 times and take a median to ensure precise measurement. The resulting FPS is then one over average rendering time for all test images. In the rendering time, we only include the rendering part, not the time required to move the data from GPU memory at the end of the rendering. When reporting the number of Gaussians #G, we report the average number of Gaussian loaded in GPU memory when rendering. For methods which constructs LOD splits on the fly this is the total number of Gaussians in all LOD sets (if applicable). Note, that for Scaffold-GS [20] and Octree-GS [28], some attributes (colors) are not stored explicitly, but are decoded on- on-the-fly fly lowering memory requirements. All baselines and our method were trained and evaluated on single NVIDIA A100 SXM4 40 GB GPU.
Baselines. For the baselines, we include the following: Zip-NeRF [2] which is the current state- of-the-art on the Zip-NeRF dataset. Note, that this method was trained for 200K iterations much longer than other baselines and does not achieve real-time rendering. We only include it for reference. RadSplat [25] uses NeR-N for initialization and is, therefore, much more expensive to train than other baselines. It uses the same strategy as our method remove less important Gaussians during training. The method used Zip-NeRF checkpoint trained for 200K and performed additional 45K training iterations to optimize 3DGS representation. 3DGS [10] is the basis for most other methods. We use the default parameters, training for 30K iterations. Mip-Splatting [37] augments 3DGS with antialiasing 2D and 3D filters. In our method, we also use the same 2D filter and we use the 3D filter when building LOD levels. Scaffold-GS [20] reduces memory requirements by decoding attributes of Gaussians on the fly from MLP. Therefore it is important baseline for rendering speed as our method stores all attributes explicitly. H3DGS [11] starts from a 3DGS representation optimized at the finest level (same as ours) and builds representation by iteratively merging Gaussians, however, at render time all Gaussians need to be kept in memory and LOD split needs to be built with every
21

---

rendering call. The method is currently SoTA for the Hierarchical 3DGS dataset. The FLOD [29]. CityGS [18], and Octree-GS [28] are both recent LOD 3DGS-based approaches. Octree-GS was trained for 40K iterations, while FLOD used 100K iterations for the 5 L.OD levels. At rendering. we use the selective 3, 4, rendering split. For all baselines we modified the code to accept masks (masking loss gradient propagation in masked regions). We have performed limited hyperparameter search to get best performance for the datasets.
A.5 Broader Impact
We are not aware of any potential misuse of our method. On the contrary, we believe it enables positive applications, particularly by making large-scale 3D reconstructions deployable on mobile and resource-consee constraicd devices. This can enhance navigation in complex urban environments, support AR experiences, and improve accessibility for users with visual impairments. Our method may also benefit fields like robotics, autonomous driving, and cultural heritage preservation by providing efficient scene representations.
22


Reviews:
[{"review_id": "Y6fRaZ6cmA", "reviewer": "Reviewer_3YiK", "summary": "The authors propose a novel Level-Of-Detail (LOD) method for 3D Gaussian Splatting, which effectively reduces computational and memory overhead for large-scale scene rendering while maintaining high-fidelity results. At the core of the method is a hierarchical LOD representation combined with a novel scene partitioning based on the Voronoi scene clustering. To further enhance rendering quality and efficiency, the paper introduces a depth-aware 3D smoothing filter and importance-based pruning for the LOD representation. To address potential boundary artifacts caused by scene clustering, an opacity-blending mechanism is incorporated.\n\nOne of the key advantages of the proposed method is that it eliminates the need for per-frame recomputation of active Gaussians, enabling dynamic loading of only the relevant splats for each view. The method is evaluated on two scenes from the Hierarchical 3DGS dataset and three scenes from the Zip-NeRF dataset, achieving state-of-the-art rendering performance while outperforming concurrent approaches such as H3DGS, OcreeGS, and FLOD in terms of memory usage and rendering efficiency. The authors also demonstrate the practical efficiency of their approach by testing in on multiple mobile devices, including iPhones and laptops.", "questions": "- How large is each chunk, and what is the computational or memory overhead associated with dynamic chunk loading? Is this overhead negligible, or does it impact the overall efficiency of the system? It would be helpful to include additional evidence or quantitative data to support the claimed efficiency of the dynamic loading mechanism.\n\n- Is K-means clustering sufficient for effective scene partitioning? Given that scene visibility is heavily influenced by camera orientation, not just position, relying soly on camera positions for clustering may be suboptimal, especially in cases where visible regions are distant and viewing directions vary widely. Could you clarify whether your method accounts for camera orientation during clustering or selection? Additionally, can you provide more evidence that your partitioning strategy generalizes well to viewpoints with orientations different from those seen during training or cluster centers?", "limitations": "yes", "rating": 5, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths\n- The proposed scene clustering strategy offers significant efficiency improvements over prior LOD representations such as OctreeGS and H3DGS, which require per-frame computation to extract active Gaussians. By eliminating the need for these computations, the method enables dynamic loading of only the relevant Gaussians, resulting in substantial gains in both computational speed and memory usage. The practical efficiency is convincingly demonstrated through deployment on mobile devices, including iPhones and laptops.\n- The method shows notable improvements in rendering quality, particularly in challenging regions such as far-distance views and close-up reflective surfaces. As illustrated in Figures 5 and 6, the proposed method captures subtle visual details that are missed by concurrent approaches.\n- The experimental evaluation and ablation studies are well-structured and sufficiently comprehensive. The paper provides clear comparisons against strong baselines (e.g., H3DGS, OctreeGS), and the effectiveness of individual components is properly evaluated to support the overall claims.\n\nWeaknesses\n- The mechanism for dynamic loading at chunk boundaries is not described in sufficient detail. Since the paper emphasizes rendering and memory efficiency, it would be valuable to explain how chunk-level loading is managed to avoid artifacts and ensure consistent performance, especially near boundaries.", "was_revised": true, "final_justification": "Most of my concerns have been adequately addressed through the rebuttal process, and I will maintain my current score. While I still have a few questions, as mentioned in my review, they are minor compared to the overall contribution of this paper.", "rebuttal": "We thank the reviewer for the constructive feedback and will adjust the paper based on their comments and the rebuttal.\n\n### **\\[W1\\] Dynamic loading not described in sufficient detail**\n\nAs described in section “Opacity blending for smooth cross-chunk transitions.” (L179-196), we take the two closest chunk centers and use their sets of Gaussians (as active Gaussians) on which we apply opacity blending. The dynamic loading means we load the active Gaussians’ properties (means, colors, etc.) into GPU memory. When the two closest chunks change (after passing the centre of the chunk), we remove the Gaussians from the previous chunk, keep the ones from the closest one, and load Gaussians from the next closest. The opacity blending at this point assigns weights close to 1 to all Gaussians from the closest chunk so there are no artifacts during loading the next chunk. We will add these details to the paper.\n\n### **\\[Q1\\] Memory overhead of dynamic chunk loading**\n\nThe chunk size depends on the 3D scene but for outdoor scenes the chunk sizes range between 3-5 meters. The overhead ultimately depends on the concrete implementation. In our experience (CUDA, WebGPU), the memory move is fast (15.26ms on CUDA with 877K Gaussians) and dynamic loading can be done asynchronously with the rendering, not slowing the rendering process.\n\n### **\\[Q2\\] Effectivity of K-means, dependency on camera orientations, generalization to novel viewpoints**\n\n**Using orientations in LOD chunks construction**  \nFor K-means clustering, we only use the camera positions, not the orientations. Note, that the projected size of a Gaussian only depends on camera position (distance), not viewing direction. Therefore, for LOD chunk construction, only camera positions need to be taken into account. While we further use visibility filtering (originally proposed in RadSplat), it is not as important as LOD Gaussians selection, and while visibility filtering increases performance (see rows 7 and 8 in Table 4), it is not critical for the method to work (compared with rows 6 and 7). While we believe that taking orientations into account could reduce the number of Gaussians by a large factor (e.g., the Gaussians behind the camera would not be included in the chunk, effectively halving the number of required Gaussians). However, reloading chunks would not be feasible with very fast camera rotations (as common in AR/VR). This is also the reason why orientations weren’t used in RadSplat, which first proposed the idea of visibility filtering. We will clarify this in the paper and extend the discussion. \n\n**Is K-means clustering sufficient for effective scene partitioning?**  \nWe believe other strategies, e.g., a regular grid, could work just as well for some types of captures where the camera density is constant in the 3D scene. However, K-means is very general and can be applied to any type of capture/3D scene as it directly operates on camera poses and does not assume any capture trajectory. \n\n**Does the chunking strategy generalize outside cluster centers?**  \nBased on the evidence in Figure 7 and in the attached video, we conclude that the partitioning strategy generalizes to positions outside of cluster centers. Even when the selection is suboptimal (further from the cluster center), more Gaussians are selected than is strictly necessary to account for not being in the cluster center. This is because we use “depths offset by the chunk radius (distance to next closest chunk center) to ensure sufficient resolution for all camera positions inside the chunk“ (L171). This means that we usually take a larger set of Gaussians than is strictly necessary, to ensure sufficient coverage according to the Nyquist sampling theorem. While some Gaussians could project into sub-pixel sizes, the smallest Gaussians of each LOD level will cover at most a pixel \\- avoiding blurring at the target resolution.\n\n**Does the chunking strategy generalize outside training cameras distribution?**  \nRegarding generalization outside training cameras distribution, unfortunately we don’t have any guarantees on the reconstruction quality outside of training cameras distribution. However, we would like to point out that most NVS methods \\[1,2,3,4,6,7,9,10,...\\] are evaluated inside the training camera distribution and fail when the camera moves (or rotates) away from the training camera distribution. Since we cannot guarantee a good quality outside of training camera distribution even with our base model (since there are no constraints to guide the reconstruction there). Our LOD strategy selects the visible Gaussians based on training cameras and as shown in Table 3 it will neither “fix” the errors in underconstrained parts of the scene, nor will it make the problem worse. E.g., if the concern is that LOD will prune some Gaussians from a certain viewpoint because the scene was never seen from that viewpoint during training, the quality of the rendering from that viewpoint will be low anyway since there was no supervision for the base representation."}, {"review_id": "5cxBtjnlqe", "reviewer": "Reviewer_LUYZ", "summary": "LODGE proposes a systematic solution to large-scale scene NVS task. The core designs are: an LOD structure for managing the rendering overhead according to view distance, a cluster-based chunk partition to reduce the number of loaded gaussians, and an opacity interpolation scheme for removing the visual artifacts when moving across different chunks. In the experiments, the proposed method achieves most efficient rendering speed with SOTA rendering quality in both indoor and outdoor scenes.", "questions": "Please add comparisons with CityGS.", "limitations": "Yes.", "rating": 5, "confidence": 5, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 4, "originality": 2, "strengths_and_weaknesses": "Strengths:\n\n+: The experimental results are solid across different scenes. And both the visual quality and rendering speed are impressive, exhibiting an applicable solution for large-scale scene rendering. \n\n+: The pipeline of constructing the LOD structure is interesting, from the finest level to the coarse level. \n\n+: The paper are well-presented, making it easy to follow.\n\nWeakness:\n\n-: Large-scale reconstruction is a classic topic and many previous work on these topic are not compared, like CityGS[1], Level of Gaussians, etc. And, for reconstructing lod from finest level, the author should cite [2].\n\n-: It's not clear how the author get the full representation model in Table 3, whose quality seems to be higher than all other baselines.\n\n[1] CityGaussian: Real-time High-quality Large-Scale Scene Rendering with Gaussians\n\n[2] PRoGS: Progressive Rendering of Gaussian Splats", "was_revised": true, "final_justification": "After reading the rebuttal and discussion, I keep my original score.", "rebuttal": "We thank the reviewer for the constructive feedback and will adjust the paper based on their comments and the rebuttal.\n\n### **\\[W1, Q1\\] Comparison with CityGS, Level of Gaussians, including PRoGS in Related work**\n\n**Comparison with CityGS**  \nWe thank the reviewer for the suggestion of comparing with CityGS \\[17\\]. We evaluated CityGS on all scenes (given the time constraint, we did our best to tune hyperparameters). The results are shown in the table below and will be included in the paper. We show the results compared to some of the baselines (for a complete set of baseline results, please take a look at Tables 1, and 2). As can be seen, our method outperforms CityGS in most metrics except for PSNR on H3DGS/Campus and ZipNeRF/Alameda, but in these cases, the difference in PSNR is small while we achieve much faster rendering and use less Gaussians.\n\n**H3DGS results**\n\n| Method | SC (PSNR / SSIM / LPIPS / \\#G / FPS) | Campus (PSNR / SSIM / LPIPS / \\#G / FPS) |\n| :---- | :---- | :---- |\n| Zip-NeRF \\[1\\] | 24.78 / 0.770 / 0.381 / — / 0.09 | 21.34 / 0.768 / 0.422 / — / 0.20 |\n| H3DGS \\[10\\] | 26.42 / 0.807 / 0.331 / 7093 K / 38.07 | 24.60 / 0.798 / 0.396 / 6186 K / 34.32 |\n| FLOD \\[28\\] | 24.82 / 0.758 / 0.429 / 497 K / 208.41 | 24.10 / 0.777 / 0.453 / 595 K / 120.61 |\n| OctreeGS \\[27\\] | 25.98 / 0.807 / 0.326 / 1008 K / 120.27 | 25.22 / 0.800 / 0.408 / 642 K / 119.21 |\n| **CityGS \\[17\\] w/o LOD** | **25.96 / 0.787 / 0.379 / 1743 K / 97.29** | **24.58 / 0.798 / 0.415 / 1254 K / 102.81** |\n| **CityGS \\[17\\]** | **25.29 / 0.772 / 0.401 / 2615 K / 114.07** | **24.82 / 0.794 / 0.419 / 1881 K / 121.67** |\n| Ours | 26.57 / 0.815 / 0.325 / 877 K / 257.46 | 24.75 / 0.803 / 0.394 / 1464 K / 218.96 |\n\n**Zip-NeRF results**\n\n| Method | PSNR (A) | SSIM A) | FPS (A) | PSNR (L) | SSIM (L) | FPS (L) | PSNR (N) | SSIM (N) | FPS (N) |\n| :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- |\n| *Zip-NeRF* \\[1\\] | 22.97 | 0.738 | 0.13 | 26.76 | 0.822 | 0.13 | 28.21 | 0.845 | 0.13 |\n| H3DGS \\[10\\] | 22.21 | 0.739 | 27.82 | 26.34 | 0.823 | 30.49 | 27.28 | 0.849 | 33.11 |\n| FLOD \\[28\\] | 21.35 | 0.666 | 276.52 | 24.38 | 0.753 | 195.06 | 25.01 | 0.781 | 260.85 |\n| OctreeGS \\[27\\] | 22.94 | 0.734 | 119.83 | 26.04 | 0.817 | 153.06 | 27.05 | 0.839 | 146.29 |\n| **CityGS \\[17\\] w/o. LOD** | **22.49** | **0.727** | **144.73** | **25.76** | **0.808** | **55.63** | **26.47** | **0.837** | **122.59** |\n| **CityGS \\[17\\]** | **22.43** | **0.729** | **174.07** | **25.87** | **0.809** | **190.10** | **26.55** | **0.839** | **144.91** |\n| Ours | 22.41 | 0.741 | 229.99 | 26.34 | 0.818 | 252.58 | 27.40 | 0.849 | 280.22 |\n\n**Comparing with Level of Gaussians**  \nWe considered including Level of Gaussians (LoG) in the Related Work section/comparison, but since there is no paper yet, only a public implementation, we believed the work is still under progress and the method itself (and the results obtained from the current implementation) might be subject to (significant) changes. We hope to include LoG in a future revision of the LODGE paper (after there is a paper or preprint for LoG).\n\n**Including PRoGS in Related Work**  \nThank you for the suggestion, we will cite PRoGS in the revised version.\n\n### **\\[W2\\] Performance of full representation in Table 3\\.**\n\nThe results in Table 3 were conducted on the H3DGS/SmallCity scene. The last row (our full model) corresponds to the entry “ours” in Table 1\\. Our base model (row 1 in Tab. 3\\) is similar to H3DGS, but it has a higher PSNR. This is caused by 1\\) not using depthmaps (which may be a source of noise in H3DGS as shown in the reported numbers), and 2\\) using the importance pruning approach from RadSplat, which also reduces floaters without the need for depth supervision. We will clarify this in the paper."}, {"review_id": "QnH2D4LMP5", "reviewer": "Reviewer_ZQhv", "summary": "This paper modifies the existing LoD rendering mechanism of 3DGS, enabling improved efficiency and rendering quality. It also facilitates the real-time high-fidelity rendering of 3DGS on low-end devices. The key ideas include pruning-based LoD generation, chunk-based LoD rendering, and visibility filtering, and the authors provide a good implementation.", "questions": "See \"Strengths And Weaknesses\".", "limitations": "Yes, the limitation has been adequately addressed.", "rating": 4, "confidence": 5, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 3, "significance": 3, "originality": 1, "strengths_and_weaknesses": "Quality: The qualitative and quantitative comparison provides solid support for the superiority of the proposed method. The test on low-power devices is also impressive. However, in the ablation (Tab. 3), the performance difference of some model designs seems to be minimal, especially for PSNR and time cost. It is hard to distinguish the performance gain from random noise. The authors should report the average results of multiple runs to get convincing conclusions.\n\nClarity: Good, easy to read.\n\nOriginality: Relatively weak. The key idea, pruning-based LoD generation, chunk-based LoD rendering, and visibility filtering, has been discussed in CityGaussian. Other techniques like importance pruning and 3D filter also come from previous works.\n\nSignificance: A meaningful step towards LoD-based 3DGS rendering on low-end devices.", "was_revised": true, "final_justification": "My concern has been resolved. Therefore I would like to raise the score to borderline accept.", "rebuttal": "We thank the reviewer for the constructive feedback and will adjust the paper based on their comments and the rebuttal.\n\n### **\\[W1\\] Minimal performance difference in Tab. 3**\n\n**PSNR and time cost seems to be similar for rows Tab 3**  \nThe contributions proposed in the paper were not intended to increase the reconstruction quality (as measured by PSNR, LPIPS, and SSIM). Instead the main focus is to reduce a) rendering times, and b) reduce the number of Gaussians needed to be loaded in memory to enable deployment on memory-restricted (mobile) devices. To this end, we show that the PSNR stays similar to the full representation after adding each contribution, while we either reduce rendering time and/or the memory requirements. The aim of Tab. 3 is to show the following:\n\n- As discussed on lines 247-257, rows 1-5 show that the PSNR stays the same while adding LOD levels decreases the rendering time. At a certain point, adding further LOD levels does not gain much in terms of rendering speed, which validates our design choice of only using 3 layers of LOD (2 depth thresholds)  \n- Row 6 and row 3 demonstrate that our automatic threshold selection procedure achieves the same quality while rendering significantly faster (L255)  \n- Rows 7 and 8 further validate the chunk-based rendering since it reduces rendering time, and much more importantly, also drastically reduces the number of Gaussians loaded into memory  \n- Finally, comparing rows 8 and 9, we show that the opacity blending procedure does not reduce quality (PSNR) and the increase in rendering time is not large. The numbers do not fully demonstrate the need for the opacity blending. However, the qualitative results in Figure 7 and especially the video in the supplementary material clearly show the need for the opacity blending procedure, which removes artifacts on chunk borders.\n\n**Authors should report average over multiple runs**  \nAs for the metrics, we follow standard practice in the literature \\[1,2,3,4,6,7,9,10,...\\]  and report the average results over the test set as it is infeasible to train multiple times on the same scene due to the large computational requirements.\n\n###  **\\[W2\\] Relatively weak originality**\n\nWhile the pruning-based LoD generation was tackled in CityGaussian (which used LightGaussian to build lower-quality representations of the same 3D scene), we believe our approach is a more principled solution to the problem: We explicitly reason and condition on the smallest possible size of Gaussians for the LoD level (in contrast LightGaussian builds LoD levels by simply pruning Gaussians with low importance score without constraints on Gaussian sizes). We use a 3D filter (same as in Mip-Splatting), but our use is very different from Mip-Splatting. While Mip-Splatting computes a 3D filter for each Gaussian based on the distance to the closest camera, we instead apply a 3D filter on the entire LOD level as a whole to restrict the size of the smallest Gaussians according to Nyquist sampling theorem. Note, that Mip-Splatting 3D filter changes during training for each Gaussian while in our case the 3D filter is constant and same for all Gaussians in the LoD level. To the best of our knowledge, using the 3D filter to build a LoD representation is a novel idea that has not been explored before."}, {"review_id": "z6HVNX227u", "reviewer": "Reviewer_cmoR", "summary": "This paper presents LODGE, a hierarchical level-of-detail (LOD) method for 3D Gaussian Splatting (3DGS), designed to enable real-time rendering of large-scale 3D scenes even on memory-constrained devices such as mobile phones. The core approach constructs a chunk-based spatial partitioning with depth-aware smoothing and importance-based pruning to reduce the number of active Gaussians. By precomputing Gaussian sets per chunk and employing an opacity blending mechanism, the method ensures smooth transitions between chunks during rendering. Experimental results demonstrate state-of-the-art rendering quality and speed while achieving notable memory and computational efficiency. However, despite its practical benefits, the method draws heavily on prior LOD-based 3DGS work, with limited technical novelty in its core contributions.", "questions": "- Given that the core LOD representation follows established 3DGS approaches [1-2], could the authors more clearly articulate what specific gaps in prior work motivated the proposed chunk-based rendering scheme? In particular, what limitations of existing LOD methods does this chunk-based strategy uniquely address?\n\n- How does this work advance the field beyond incremental improvements to prior LOD-based 3DGS systems? Are there any fundamental rendering challenges that this chunk-based paradigm solves that were previously intractable with conventional LOD methods? \n\n- Given that loading the union of Gaussian sets from adjacent chunks may cause prohibitive memory peaks, could the authors discuss potential optimization strategies to maintain real-time performance on resource-constrained mobile devices? \n\n- The method appears sensitive to oblique camera trajectories that deviate from inter-chunk axes. Could the authors analyze the theoretical bounds of acceptable camera motion angles before artifacts occur? Would a view-dependent blending weight (e.g., incorporating camera direction) improve robustness? \n\n- Static thresholds seem suboptimal for dynamic scenes. What prevents the implementation of runtime threshold adjustment based on real-time performance monitoring? Would a feedback loop from the renderer to the LOD controller be feasible?\n\n[1] Ren K, Jiang L, Lu T, et al. Octree-gs: Towards consistent real-time rendering with lod-structured 3d gaussians[J]. arXiv preprint arXiv:2403.17898, 2024.\n\n[2] Kerbl B, Meuleman A, Kopanas G, et al. A hierarchical 3d gaussian representation for real-time rendering of very large datasets[J]. ACM Transactions on Graphics (TOG), 2024, 43(4): 1-15.", "limitations": "The current limitations section is too narrow. Beyond Gaussian streaming assumptions, the authors should discuss: Scalability to dynamic scenes, Sensitivity to camera paths, Runtime memory spikes, Generalization of depth thresholds, Training overhead, Failure cases and performance degradation. Moreover, recently published related works such as LOD-GS [4] should be discussed to situate the contribution more thoroughly in the current landscape.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 3, "significance": 2, "originality": 2, "strengths_and_weaknesses": "Strengths\n1. The paper is well-organized and easy to follow, making the technical approach accessible to the reader.\n\n2. The chunk-based rendering strategy improves rendering efficiency and significantly reduces GPU memory usage, which is crucial for real-time mobile deployment.\n\n3. The proposed opacity blending mechanism between adjacent chunks is an effective solution for minimizing visual discontinuities, a common artifact in LOD-based rendering.\n\n4. Experimental results show clear advantages over existing baselines, including in terms of runtime and memory consumption.\n\nWeaknesses\n\n1. Limited Technical Novelty\n\nThe proposed method largely builds on existing LOD-based 3D Gaussian Splatting approaches such as Octree-GS [1] and H3DGS [2], without introducing fundamentally new mechanisms. The chunk-based design appears more as an engineering integration of existing ideas rather than a conceptual innovation, and the contributions listed in the paper partially overlap and should be clarified.\n\n2. Inadequate Analysis of Prior Work\n\nWhile the paper mentions that existing LOD methods are inefficient or memory-heavy, it lacks a detailed technical analysis of why these approaches fall short. A more rigorous comparison—especially regarding memory scheduling, rendering consistency, and scalability—is needed to motivate the proposed solution.\n\n3. Chunk Boundary Issues and Visual Artifacts\n\nThe method encounters significant challenges when handling Gaussians near chunk boundaries. Although opacity blending helps, the requirement to load the union of adjacent Gaussian sets leads to memory spikes. In scenarios where the camera moves diagonally across chunks, visible artifacts may still occur due to insufficient blending robustness.\n\n4. Depth Threshold Selection and Adaptability\n\nThe depth threshold is selected via a greedy empirical search, lacking theoretical support or dynamic adaptability. This raises concerns about generalization and performance under changing viewpoints or in dynamic scenes. Moreover, the current design does not address spatial load imbalance, which may result in localized computational bottlenecks.\n\n5. Methodological Clarity and Justification\n\nKey methodological choices—such as the use of K-means clustering for chunk division and the opacity blending function—are insufficiently justified. The geometric intuition behind blending is unclear, and the influence of clustering parameters on rendering quality and performance is not analyzed.\n\n6. Evaluation Limitations and Fairness\n\nThe evaluation setup lacks fairness in GPU memory comparisons: competing methods are assumed to keep all Gaussians in GPU memory, while the proposed method benefits from streaming. A consistent memory evaluation protocol is necessary. Additionally, only two scenarios from the H3DGS dataset are used, limiting claims of generalizability.\n\n7. Missing Ablation and Sensitivity Analyses\n\nThe ablation study does not separately examine the impact of the threshold selection or number of LOD levels. These factors directly influence rendering quality and efficiency, and their effects should be studied quantitatively.\n\n8. Missing Related Work\n\nA relevant and recent work, LOD-GS [4], is not cited or discussed. This omission weakens the positioning of the paper in the context of current research and should be addressed with a proper comparison and discussion.\n\n[1] Ren K, Jiang L, Lu T, et al. Octree-gs: Towards consistent real-time rendering with lod-structured 3d gaussians[J]. arXiv preprint arXiv:2403.17898, 2024.\n\n[2] Kerbl B, Meuleman A, Kopanas G, et al. A hierarchical 3d gaussian representation for real-time rendering of very large datasets[J]. ACM Transactions on Graphics (TOG), 2024, 43(4): 1-15.\n\n[3] Seo Y, Choi Y S, Son H S, et al. FLoD: Integrating Flexible Level of Detail into 3D Gaussian Splatting for Customizable Rendering[J]. arXiv preprint arXiv:2408.12894, 2024.\n\n[4] Shen J, Qian Y, Zhan X. LOD-GS: Achieving Levels of Detail using Scalable Gaussian Soup[C]//Proceedings of the Computer Vision and Pattern Recognition Conference. 2025: 671-680.", "was_revised": true, "final_justification": "The authors have provided a careful and thorough response to my comments and have satisfactorily addressed my concerns. Therefore, I would like to raise my score.", "rebuttal": "We thank the reviewer for the constructive feedback and will adjust the paper based on their comments and the rebuttal.\n\n### **\\[W1, W2, Q1, Q2\\] Clarifying relation to prior work, limited technical novelty**\n\n**\\[W2, Q1, Q2\\] Which gaps in prior work motivated LODGE**  \nThe focus of our method is to enable rendering of large-scale 3DGS scenes on memory-restricted devices. Unlike traditional mesh-based rendering pipelines, where LOD reduces the amount of primitives required to be loaded and stored in memory, existing 3DGS LOD approaches (e.g., Octree-GS, and H3DGS) only focus on the rendering speed and they ignore the memory aspect of LoD representation. While rendering speed is key in many applications, the large memory requirements imposed by existing 3DGS LOD methods is a limiting factor preventing 3DGS to truly scale to large scenes and small-memory devices (as shown in Tab. 4). We believe to be the first to address the LOD problem from the practical perspective of reducing the number of Gaussians needed to be kept in memory and thus to enable rendering on memory restricted devices \\- something which cannot be achieved by existing approaches.\n\n**\\[W1, W2, Q1\\] What is the novelty wrt. Octree-GS and H3DGS**  \nExisting approaches (both Octree-GS and H3DGS) are fundamentally different from our approach in that for each rendered frame, they first need to compute a subset of Gaussians to be processed by the renderer. To this end, they require all Gaussians to be loaded in memory, which is prohibitive/infeasible for systems with restricted memory, e.g., mobile devices, as we show in Table 4\\. To resolve this issue, we propose a novel LOD rendering strategy with chunk-based caching. Our approach is technically novel and not based on either Octree-GS nor H3DGS. Detailed experiments show the effectiveness of our approach.\n\n**\\[W1\\] Overlapping contributions**  \nThe contributions stated are the following: 1\\) LOD representation, 2\\) automatic LOD split selection procedure, 3\\) per-chunk caching, 4\\) opacity blending. We believe there are no overlaps as each describes a different contribution as can be seen in Table 3 where we selectively add each one to the base model.\n\n### **\\[W3,Q3\\] Chunk boundary issues and visual artifacts**\n\n**\\[W3, Q3\\] Memory spikes at crossing chunk centers**  \nIn our experience, opacity blending does not lead to memory spikes in practical implementations. Without opacity blending, the point where we need to reload the set of Gaussians would be when crossing chunk boundaries. Therefore we would have to load both chunks into memory and we would have a sharp change of appearance. With opacity blending, we shifted the point where we need to reload Gaussians to the center of the chunk. Close to the center, there are no sharp changes if we only use the chunk’s set of Gaussians, and, therefore, we can unload the previous chunk and load the next one without the memory spike. We will add this more in-depth discussion to the paper. \n\n**\\[W3\\] Diagonal camera movement**  \nRegarding the diagonal movement across chunks \\- we agree that there could be artifacts visible in certain cases. However, in commonly used datasets we do not observe artifacts (we tested on H3DGS, Zip-NeRF, Mip-NeRF 360 datasets and on additional non-public data).   \nWe believe the reason to be the following:\n\n- Close to the training camera distribution, the same viewpoint when rendered from the closest chunks will be almost the same as the different chunks are well conditioned by training cameras and artifacts are minor even without opacity blending.  \n- The viewpoints outside of this distribution are on the boundary of the chunk-based representation and only the two closest chunks (from inside the training camera distribution) have a sizable effect on it. Therefore, using 2 closest chunks is sufficient in this case.\n\nWe will extend the discussion in the paper.\n\n### **\\[W4\\] Depth threshold selection and adaptability**\n\nThe depth threshold is chosen to minimize the number of processed Gaussians identified as a bottleneck of 3DGS rendering. A theoretical analysis of 3DGS renderer is not really realistic as the rendering speed depends on CUDA characteristics, tiny implementation details, but most importantly on the 3D scene structure itself. Therefore, we believe only empirical evaluation is possible. To support the greedy search, in Figure 4, we show the convex property of the number of processed Gaussians as a function of depth thresholds.  \nRegarding the spatial load imbalance, we would like to argue that all current NVS approaches consider and are evaluated on the set of test cameras whose distribution matches the train cameras distribution. Our approach is no different in that it also assumes that the set of cameras at inference will have the same distribution and therefore the automatic procedure produces good thresholds. If the camera moves outside of this distribution, the threshold selection might become suboptimal, but at train time using the training camera distribution is the only information available.\n\n### **\\[W5\\] Methodological clarity and justification**\n\n**Justification of K-means**  \nPlease refer to the answer to Q2 for reviewer 3YiK.\n\n**Intuition behind blending**  \nPlease see answer to W1 for reviewer 3YiK. The justification for opacity blending \\- blending alphas of two sets of Gaussians \\- is to interpolate between the two 3D scene representations of the two chunks. Using the projection of the camera position onto the line connecting the two chunk centers was chosen to make the interpolation function exactly 1 when passing through chunks but not exactly through chunk centers. We believe different choices of this function are also possible as long as this property holds and the function is smooth. In our experiments our choice worked well and we didn’t explore other options.\n\n### **\\[W6\\] Evaluation limitations and fairness**\n\n**Fairness in GPU memory comparisons**  \nWe report the number of Gaussians needed when running the rendering pass. Ultimately evaluating GPU memory usage is difficult as there are many choices possible. For example, we could measure peak GPU usage, but that is very much dependent on actual rasterizer implementation rather than on fundamental properties of the methods. Note, that some methods can use a lower SH degree or compress the attributes (OctreeGS, ScaffoldGS), which will reduce the memory usage, but a similar compression can be applied to other approaches and is not a fundamental property of the approach.  \nWe believe reporting the number of Gaussians required to be loaded in memory when running the rendering is a fair proxy as it is comparable across various implementation and compression techniques and measures the more fundamental property of various LoD approaches.\n\n**Competing methods are assumed to keep all Gaussians in GPU memory**  \nThe competing methods compute LOD split on the fly \\- unlike our chunk-based strategy \\- and, therefore, need at least the positions of all Gaussians in memory at all times. Therefore, streaming Gaussians into memory is not feasible for these methods which was the main motivation for our approach \\- to enable rendering in cases when not all Gaussians fit into the memory (e.g. mobile devices).\n\n**Using only two scenarios from H3DGS**  \nWe used the only two 3D scenes for H3DGS which are public (see the official H3DGS project webpage). We do not have access to the private Waywe data used in H3DGS.\n\n### **\\[W7\\] Missing ablation and sensitivity analysis**\n\nIn the ablation study in Table 3, rows 2, 3, 4, 5 quantitatively evaluate the impact of the number of LOD levels on rendering quality, rendering speed, and memory consumption. Comparing rows 2 and 6 shows the impact of threshold selection.\n\n### **\\[W8\\] Missing related work**\n\nLOD-GS was published at CVPR 2025\\. The paper does not seem to have been publicly available before the CVPR 2025 proceedings were published (June 12th, about a month after the NeurIPS submission deadline). We are happy to add a discussion of this work, but it was impossible to have been aware of this work by the time of submission.\n\n### **\\[Q4\\] Sensitivity to trajectories outside inter-chunk axes**\n\n**Oblique camera trajectories deviating from inter-chunk axes**  \nPlease refer to the answer to Q2 for reviewer 3YiK.\n\n**View dependent blending weights**  \nThe chunks were constructed based on camera positions (distances to chunk centers) only. Therefore, we don’t think there would be any benefit in using viewing directions in opacity blending.\n\n### **\\[Q5\\] Dynamic scenes and on-the-fly threshold adjustment**\n\n**Dynamic scenes with LODGE**  \nIn our work we only focussed on static scenes. With this assumption, we build the chunks which then stay fixed for the rendering. In most dynamic scenes, only a small portion of the 3D scene moves and the rest stays static (e.g. see \\[4\\]). In this setup, the dynamic object is likely small compared to the static part of the scene and does not need any LOD strategy and our approach is directly applicable.\n\n**Real-time threshold adjustment**  \nAfter adjusting thresholds, LOD chunks need to be recomputed. We cannot do that for every frame, because we would end up in the same situation as prior works which require Gaussians to be loaded in memory at all times. However, once in a while we can rebuild LOD chunks based on new thresholds. In our case, we didn’t need to consider this scenario as we didn’t see a practical use for it."}]

Author rebuttal:

Meta-review: The paper presents a novel and practical approach to large-scale 3D Gaussian Splatting with an effective LOD mechanism, dynamic chunk-based rendering, and memory-efficient strategies, validated through thorough experiments on indoor and outdoor datasets and low-power devices. All four reviewers acknowledge the solid technical contributions, strong evaluation, and practical impact, with minor clarifications addressed satisfactorily in the rebuttal. The decision to accept this paper has been approved by the SAC. We recommend that the authors incorporate the reviewers’ suggestions regarding chunk-based rendering, opacity blending, orientation handling, and clarifications in tables and methodology into the final version to ensure clarity and completeness.
Decision: Accept (spotlight)