LODGE: Level-of-Detail Large-Scale Gaussian Splatting with Efficient Rendering

We thank the reviewer for the constructive feedback and will adjust the paper based on their comments and the rebuttal.

**

$W1, W2, Q1, Q2$ Clarifying relation to prior work, limited technical novelty**

** $W2, Q1, Q2$ Which gaps in prior work motivated LODGE**
The 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.

** $W1, W2, Q1$ What is the novelty wrt. Octree-GS and H3DGS**
Existing 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.

** $W1$ Overlapping contributions**
The 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.

**

$W3,Q3$ Chunk boundary issues and visual artifacts**

** $W3, Q3$ Memory spikes at crossing chunk centers**
In 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.

** $W3$ Diagonal camera movement**
Regarding 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).
We believe the reason to be the following:

• 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.
• 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.

We will extend the discussion in the paper.

**

$W4$ Depth threshold selection and adaptability**

The 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.
Regarding 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.

**

$W5$ Methodological clarity and justification**

Justification of K-means
Please refer to the answer to Q2 for reviewer 3YiK.

Intuition behind blending
Please 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.

**

$W6$ Evaluation limitations and fairness**

Fairness in GPU memory comparisons
We 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.
We 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.

Competing methods are assumed to keep all Gaussians in GPU memory
The 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).

Using only two scenarios from H3DGS
We 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.

**

$W7$ Missing ablation and sensitivity analysis**

In 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.

**

$W8$ Missing related work**

LOD-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.

**

$Q4$ Sensitivity to trajectories outside inter-chunk axes**

Oblique camera trajectories deviating from inter-chunk axes
Please refer to the answer to Q2 for reviewer 3YiK.

View dependent blending weights
The 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.

**

$Q5$ Dynamic scenes and on-the-fly threshold adjustment**

Dynamic scenes with LODGE
In 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.

Real-time threshold adjustment
After 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.

We thank the reviewer for the constructive feedback and will adjust the paper based on their comments and the rebuttal.

**

$W1$ Minimal performance difference in Tab. 3**

PSNR and time cost seems to be similar for rows Tab 3
The 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:

• 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)
• Row 6 and row 3 demonstrate that our automatic threshold selection procedure achieves the same quality while rendering significantly faster (L255)
• 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
• 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.

Authors should report average over multiple runs
As 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.

**

$W2$ Relatively weak originality**

While 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.

We thank the reviewer for the constructive feedback and will adjust the paper based on their comments and the rebuttal.

**

$W1, Q1$ Comparison with CityGS, Level of Gaussians, including PRoGS in Related work**

Comparison with CityGS
We 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.

H3DGS results

Zip-NeRF results

Comparing with Level of Gaussians
We 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).

Including PRoGS in Related Work
Thank you for the suggestion, we will cite PRoGS in the revised version.

**

$W2$ Performance of full representation in Table 3.**

The 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.

We thank the reviewer for the constructive feedback and will adjust the paper based on their comments and the rebuttal.

**

$W1$ Dynamic loading not described in sufficient detail**

As 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.

**

$Q1$ Memory overhead of dynamic chunk loading**

The 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.

**

$Q2$ Effectivity of K-means, dependency on camera orientations, generalization to novel viewpoints**

Using orientations in LOD chunks construction
For 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.

Is K-means clustering sufficient for effective scene partitioning?
We 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.

Does the chunking strategy generalize outside cluster centers?
Based 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.

Does the chunking strategy generalize outside training cameras distribution?
Regarding 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.