We sincerely thank you for the very constructive comments. We are inspired and hope our discussion brings more insights. If not specified, the referred lines are from the original submission.

1. Concern about novelty

Our method adopts 2DGS primitives with CityGS's model and data division strategy but introduces novel densification and parallel training paradigms. The densification strategy addresses a series of critical challenges preventing 2DGS from trivial scaling up like 3DGS (detailed in Section 3.2, Figures 3 and 10). The latter sets a new end-to-end paradigm that unifies modules in training and compression, enabling a considerable training cost reduction. Both reviewers LweB and M9Gm have acknowledged the difficulty of the problem and the value of our solution. And the insight and novel design of the densification strategy are appreciated by reviewer tjuJ.

2. Questions regarding module ablation

• Key modules—DGD, Depth Regression, and Parallel Tuning—bring significant performance gains. DGD alone boosts PSNR by 1.1, matching the gain of ScaffoldGS [CVPR’24] over 3DGS on the TnT dataset. Combined with Depth Regression, our method exceeds 2DGS by 0.03 in terms of F1 score, similar to the NeuS [NIPS’21] vs. Geo-NeuS [NIPS’22] difference on TnT. Parallel Tuning further brings a substantial gain of 1.3 PSNR and 0.03 F1.
• The Elongation Filter doesn't directly improve performance but is critical in preventing Gaussian count explosion during Parallel Tuning (see Figure 3 and experiment in the next question). Modules including Trimming, SH Degree Adjustment, and Vector Quantization reduce storage or memory costs by at least 25%.
• Therefore, each module plays a vital role, either boosting performance or lowering resource costs.

3. Concern about comparison experiments

• Thanks for your insightful advice. Indeed, the training of existing GS-based surface reconstruction is constrained on single GPU, limiting their capacity. For instance, a single A100 40GB GPU can hold up to 11.2 million Gaussians – well below quality saturation (validated in GrendelGS [arXiv`24]). In contrast, parallel training methods like CityGS and ours can efficiently handle over 20 million points. Given these differences, strict comparability between single-GPU methods and parallel paradigms is challenging.
• Therefore, we provide a detailed comparison focusing on CityGS, our method, and 2DGS under parallel training (2DGS*). As shown in the table below, 2DGS encounters out-of-memory errors when scaling to most large-scale scenes, highlighting the importance of our optimization. For CityGS and our method, the Gaussian counts are aligned through compression for a fair comparison. The results demonstrate that our method outperforms CityGS in training time, memory cost, and geometric accuracy (F1 score). Furthermore, it shows better rendering quality under extreme compression (75% on Residence) or street view scenes. These results validate the performance advantages of our approach and have been added to the revision. The CityGS's performance in Table 2 has been updated to this aligned version in revision. |Scene|Method|PSNR$\uparrow$|F1-Score$\uparrow$|#GS(M)|T(min)|Size(G)|Mem.(G)|FPS| |---|---|---|---|---|---|---|---|---| |Residence|2DGS*|OOM|OOM|OOM|OOM|OOM|OOM|OOM| |Residence|CityGS|23.17|0.453|8.05|235|0.44|31.5|66.7| |Residence|Ours|23.46|0.465|8.07|181|0.44|14.2|45.5| |Russia|2DGS*|OOM|OOM|OOM|OOM|OOM|OOM|OOM| |Russia|CityGS|24.19|0.455|7.00|209|0.38|27.4|55.2| |Russia|Ours|23.89|0.537|6.97|177|0.38|15.0|33.3| |Modern|2DGS*|OOM|OOM|OOM|OOM|OOM|OOM|OOM| |Modern|CityGS|26.22|0.462|7.90|215|0.43|29.2|57.1| |Modern|Ours|25.53|0.489|7.90|185|0.42|16.1|34.5| |Aerial|2DGS*|OOM|OOM|OOM|OOM|OOM|OOM|OOM| |Aerial|CityGS|27.23|0.459|10.3|217|0.56|25.7|38.6| |Aerial|Ours|26.70|0.492|10.4|181|0.56|14.8|27.0| |Street|2DGS*|22.24|0.371|9.20|170|2.17|15.5|28.6| |Street|CityGS|21.12|0.398|7.63|163|0.42|11.9|50.0| |Street|Ours|22.09|0.499|7.59|149|0.42|10.8|31.3|

4. Questions about hardware and inferior rendering quality

• Yes, all experiments were conducted using 8 A100 GPUs. This information has been added to the revised manuscript for clarity.
• In the absence of additional enhancements, surface reconstruction methods, as noted in SuGaR, 2DGS, and GOF, typically show lower rendering quality than 3DGS. This is primarily due to two factors: (1) the collapse of primitives from ellipsoids to surfels reduces representation capacity, and (2) geometric constraints restrict the solution space, making it more difficult for the model to find local optimal solution of rendering quality. But it deserves noticing that though in Table 1 our method sacrifices 0.4 PSNR on average, it achieves a significant 0.22 F1-score (18.8%) improvement over CityGS, demonstrating a favorable trade-off for enhanced geometric accuracy.

Dear Reviewer k1eM,

Thanks again for your insightful comments and valuable time devoted to our paper. As the author-reviewer discussion period is coming to an end, please let us know if there's any further information we can provide to facilitate the discussion process. We are happy to answer any questions or concerns you may have during the author-reviewer discussion period.

We are highly appreciated for your time and consideration.

We really appreciate your willingness to recommend our paper for acceptance and attentive review! The responses to the main concerns are as follows:

1. Symbol confusion in lines 189-190

The error has been fixed in the revision. Thanks for reminding!

2. Details about ground plane estimation in line 352-352

• The ground plane is estimated using the ground-truth transformation matrix, which aligns the scene's vertical direction with the z-axis. By retaining only the x and y coordinates, we project the points onto the ground plane and calculate the corresponding alpha shape. These details are clarified in the revised manuscript.
• If the ground-truth matrix is unavailable, the vertical direction can be approximated using PCA on the point cloud or camera poses, enabling an approximate transformation matrix and making our crop volume estimation algorithm applicable.
• The example processes 31.4 million points with 958 training images (1080p rendering) on a single A100 GPU (40GB), covering 1.47 km², and thus is able to complete within 1 minute. For low-end devices, similar speed can be achieved by lowering the resolution. These details have been added and highlighted to the revision.

We do appreciate your valuable comments and constructive advice, which helped us a lot to make the paper better. The responses to the main concerns are as follows. If not specified, the referred lines are from the original submission.

1. Consideration of light condition

We sincerely thank you for this very constructive comment. Decoupled appearance modeling is very likely to help us improve the model's adaptability. However, our focus during this manuscript's development was on geometric accuracy and training efficiency. Thus, We chose the GauUScene and MatrixCity datasets, which have compensated or constant lighting conditions. We’ve added this to the Discussion section and plan to implement this approach in our code release.

2. Discrepancy of reported Gaussian count

Sorry for the confusion. In Table 2, the Gaussian count (w Elongation Filter) is reported on the Residence scene at the pretrain stage, where Gaussians are trained for 30,000 iterations with 2DGS’s original hyperparameters. In contrast, as depicted in Lines250-251 and Lines510-511, Figure 3 reports results on the Rubble scene at the finetuning stage, where Gaussians are divided into submodules for parallel tuning. And Figure 3 illustrates how a specific block fails to tune and how our method addresses this. As such, the reported Gaussian counts differ between these two contexts. To clarify, we have adjusted the expression and emphasized the training stage in the caption of Figure 3 and Lines510-511 in the revision.

3. Concern about Elongation Filter

• Your insightful comment on the Gaussian count is correct! Upon re-checking the results, we found that the Gaussian count for 2DGS with the Elongation Filter was mistakenly reported; the correct value is 9.36 million. We fix this in the revision and provide additional validation on all GauUScene scenes in the table below. The result shows Elongation Filter does bring a slight Gaussian count drop, but its impact on rendering and geometry performance is minimal. In the example of Figure 3, the filter reduces Gaussians with extreme elongation from 3.83 million to 0.22 million in the finetuning stage, significantly easing memory load. | 3w Iter. | SSIM↑ | PSNR↑ | LPIPS ↓ |P↑ | R↑ | F1↑ | #GS(M)| | ----------------- | ------- | --------- | --------- | :---: | :---: | :--------: | :--------: | | Residence, w/o Elongation Filter | 0.637 | 21.12 | 0.401| 0.474| 0.362| 0.410| 9.54 | | Residence, w Elongation Filter | 0.636 | 21.18 | 0.401| 0.477| 0.362| 0.411| 9.36 | | Russia, w/o Elongation Filter | 0.767 | 23.23 | 0.220| 0.497| 0.493| 0.495| 11.5 | | Russia, w Elongation Filter | 0.766 | 23.28 | 0.220| 0.493| 0.491 | 0.493| 10.4 | | Urban, w/o Elongation Filter | 0.752 | 25.20 | 0.248| 0.564| 0.395| 0.465| 9.81 | | Urban, w Elongation Filter | 0.750 | 25.16 | 0.249| 0.560| 0.396| 0.464| 9.45 |
• Considering underreconstruction, Gaussians with extreme elongation under-reconstructed areas still receive gradients, enabling expansion. Since the projected area is more sensitive to the changes of the shorter axis, it expands faster than the longer axis. When the elongation ratio exceeds a threshold, cloning and splitting can still occur, preventing the model from being stuck in under-reconstructed states. Additionally, our tests across various scenes show that extremely elongated Gaussians typically comprise less than 0.5% of all Gaussians. This leaves sufficient opportunities for neighboring Gaussians to fill in under-reconstructed areas. Empirical testing in the table above validates that the Elongation Filter has minimal impact on performance. These findings make us trust that the Gaussians, even with the Elongation Filter, have enough flexibility and redundancy to handle under-reconstruction.

4. Illustration of the paper's limitation

As suggested, a detailed discussion with an analysis of bad cases and extensive examination has been added to the main paper in revision. This enables a clearer understanding of the method's scope and potential constraints. Please refer to Page 10 of the revised version for more details.

5. The unit of metrics in Table 2

Thank you for your thoughtful comment. The units for the metrics in Table 2 are indeed specified in the corresponding caption of submission. To enhance clarity, we have italicized the unit specifications in the revised version.

Dear Reviewer tjuJ,

Thanks again for your insightful comments and valuable time devoted to our paper. As the author-reviewer discussion period is coming to an end, please let us know if there's any further information we can provide to facilitate the discussion process. We are happy to answer any questions or concerns you may have during the author-reviewer discussion period.

We are highly appreciated for your time and consideration.

We are grateful for your insightful and constructive suggestions! The responses to the main concerns are as follows. If not specified, the referred lines are from the original submission.

To begin with, we would like to re-emphasize why achieving geometrically accurate large-scale scene reconstruction is both challenging and non-trivial. While many surface reconstruction methods exist, scaling them to large-scale scenes presents significant obstacles. SuGaR suffers from the limited capacity (Figure 7) and encounters OOM when training on thousands of images due to suboptimal implementation (elaborated in response to Question 2). GOF suffers from severe underfitting, primarily due to large, blurry floaters. These floaters obstruct the field of view and hinder valid supervision (Table 1, Figure 7). While 2DGS excels in generalization, it faces slow convergence due to blurry floaters (Figures 1, 10) and Gaussian count explosion, leading to OOM (Figure 3). The OOM problem is so severe that 2DGS fails to finish parallel tuning on most scenes (Table 4 in revision). These issues highlight that scaling 2DGS is significantly more challenging than scaling 3DGS, urging the community to carefully consider surface reconstruction method design.

1. Concern about Motivation and Novelty

The aforementioned challenges strongly motivate our work, and we aim for a solution that is as simple as possible. Our method adopts 2DGS primitives with CityGS's data and model division strategy, but introduces novel densification mechanisms and parallel training paradigms. The proposed densification strategy effectively addresses the critical challenges outlined above, yet it is simple enough to implement with changes of several lines in 2DGS. Furthermore, our training pipeline sets a new end-to-end paradigm that unifies modules in training and compression, enabling a considerable training cost reduction. Regarding the densification mechanism:

• The design of Elongation Filter is based on theoretical analysis in Lines250-262:

Typically, a 2D Gaussian can collapse to a very small point when projected from a distance, especially those exhibiting extreme elongation [2DGS, Huang et al., 2024]. With high opacity, the movement of these minuscule points can cause significant pixel changes in complex scenes, leading to pronounced position gradients. As evidenced in the left portion of Figure 3, these tiny, sand-like projected points contribute substantially to points with high gradients. And they belong to those with extreme elongation. Moreover, some points project smaller than one pixel, resulting in their covariance being replaced by a fixed value through the antialiased low-pass filter. Consequently, these points cannot properly adjust their scaling and rotation with valid gradients. In block-wise parallel tuning, the views assigned to each block are much less than the total. These distant views are therefore frequently observed, causing the gradients of degenerated points to accumulate rapidly. These points consequently trigger exponential increases in Gaussian count and ultimately lead to out-of-memory errors, as demonstrated in the right portion of Figure 3.

as well as experimental examination exampled in Figure 3. As the Gaussian count explosion stems from extreme surfels, we use a straightforward solution to stop over-cloning: use elongation rate as the indicator to find these surfels and limit their densification.

• The Decomposed-Gradient-Densification mechanism is rooted in a thorough analysis of suboptimal convergence. We examine the rendering quality evolution at 1k iteration intervals across 3DGS, flattened 3DGS, and 2DGS, as illustrated in Figure 10. The results indicate that the rendering quality of both flattened 3DGS and 2DGS suffers from blurry floaters that are not split in time. This result also suggests that the problem is inherent to primitive dimension collapse. Since the densification criteria:

is dominated by loss design, the simplest way to eliminate blurriness is to adopt an appropriate gradient source. Theoretically, as detailed in Lines 280-283, SSIM loss is more sensitive to blurriness and structural difference and L1, making it suitable to solve the problem.

2. Solvement of OOM and Convergence problem of baselines

• For the OOM issue of SuGaR, the primary cause lies in its suboptimal implementation, such as retaining costful but unnecessary gradients during initialization. Although optimizing the baseline code is beyond the scope of our work, we eliminated these inefficiencies, allowing SuGaR to run successfully on MatrixCity-Aerial. The optimization led to a competitive PSNR of 22.41 and F1 score of 0.169. However, the geometry quality remains inferior to 2DGS. Both qualitative and quantitative results have been updated in the revised version.
• For the convergence failure in Table 1, we have conducted an extensive search for optimal hyperparameter combinations. Despite these efforts, the improvements were marginal. For example, reducing the scaling learning rate by fourfold upon settings in Lines410-420 improved GOF's PSNR on MatrixCity-Aerial by 0.5. But the final PSNR of 17.94—still 5 points below SuGaR—indicates significant underfitting, which prevents generating meaningful mesh. As previously discussed, the root cause of this underfitting is the presence of large, blurry floaters. Testing the same scene with MipSplatting (the foundation of GOF) produced similar issues, suggesting that the underfitting stems from the inherent design of MipSplatting rather than from hyperparameter settings.