{"id":"0a3fb947-fafc-404b-b855-be2aa38556dd","arxiv_id":"2412.07660","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"Proc-GS constrains 3D Gaussian Splatting with procedural code to extract reusable building assets and assemble new buildings and cities.","lead":"Proc-GS trains 3D Gaussian Splatting models to obey a procedural building code, so each window, corner, and pillar becomes a reusable asset. This lets users edit, duplicate, and recombine building parts and assemble whole city scenes from a small set of learned components.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 4x compression claim conflates shared base assets with per-instantiation variance assets; it is unclear whether model size scales with instance count, which is load-bearing for the central claim.","rationale":"The reader's weakest assumption focuses on the accuracy of manually obtained procedural codes for real scenes. That is a legitimate concern, but it is not the most load-bearing for the specific claim of a 4x smaller model at comparable quality on the synthetic benchmark, where code is ground truth. The more immediate gap is that the reported model size is an aggregate number that hides the split between shared base assets and per-instantiation variance assets. The ablation in Table 3 strongly suggests variance assets dominate the final count and are responsible for most of the quality recovery, so the compression ratio may not be a robust property of the shared-asset mechanism. The steep decline in compression on real scenes (1.3x vs 4x) supports this reading. I therefore propose a concrete experiment that decomposes the parameter budget and measures scaling with instance count. This does not overturn the reader's CONDITIONAL verdict; rather, it adds a specific technical condition (report base/variance split and scaling behavior) that should be satisfied before the central compression claim is taken at face value. I agree partially with the reader because both concerns are about the generalization of the results beyond the exact synthetic setup, but the specific mechanism I flag is different from the code-accuracy issue.","tokens_in":17277,"tokens_out":12502,"duration_ms":117908,"concrete_test":"Recompute Table 1 with two extra columns: the average Gaussian count of shared base assets vs variance assets per scene. Then, using the 17 MatrixBuilding buildings, construct variants with different repetition counts K from the same asset library while holding PSNR roughly constant, and plot total GS vs K for Proc-GS and vanilla 3D-GS under identical training budgets. If Proc-GS's curve has a slope close to that of 3D-GS, the 4x compression is not preserved as instance count grows, undermining the scalable city-assembly claim. A complementary check: train on one real-world scene after artificially duplicating facade instances and measure whether the compression ratio falls toward 1 as K increases.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central evidence (Table 1) reports only final total Gaussian counts. Section 3.3 says a separate 'variance asset' is created for every instantiation of every base asset, and ablation Table 3 shows that without variance assets, PSNR drops from 27.68 to 25.54 while GS count falls to 87k. Thus variance assets contribute roughly 200k of the 291k total Gaussians in the full method, meaning the 'shared foundation' is only about one-third of the final model. The compression is therefore not a pure consequence of procedural sharing; it is largely a consequence of keeping variance assets small. In real-world scenes, where per-instance appearance varies more, the compression ratio collapses to about 1.3x (500k vs 384k), consistent with this interpretation. The paper does not report the base/variance split or how total GS scales with the number of instantiations K. If total GS grows approximately linearly with K, the factor-of-4 reduction is a property of the low-diversity synthetic benchmark, not of the proposed representation, and the scaled-up city-assembly claim is unsupported. This gap is load-bearing because the central claim is that procedural sharing itself yields a 4x smaller model at comparable fidelity; that claim is not established without separating the shared and per-instance parameter budgets.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces Proc-GS, a framework that integrates procedural building code into 3D Gaussian Splatting (3D-GS). A building is decomposed into shared base assets plus per-instantiation variance assets, guided by a procedural code string. The authors introduce the MatrixBuilding dataset of 17 synthetic buildings with ground-truth procedural codes and multi-view images, and also apply the method to three real-world drone-captured scenes with manually annotated procedural codes. Experiments compare against vanilla 3D-GS for novel-view synthesis, report sparse-view results, and compare city-generation consistency (depth/camera error) against prior generative city models. The central claimed results are comparable rendering quality with roughly 4x fewer Gaussians on synthetic data, strong robustness to sparse views, and improved city-level geometric consistency.","tokens_in":17553,"tokens_out":5585,"duration_ms":48623,"significance":"If the claims hold, the paper makes a useful contribution by showing that procedural structure can be injected into 3D-GS optimization, enabling asset-level editing, reuse, and scalable city assembly. The MatrixBuilding dataset is a valuable resource for future work on structured building reconstruction. The sparse-view robustness is notable and well demonstrated. However, the headline compression claim is not cleanly established because the per-instantiation variance assets, which constitute the majority of the final Gaussian count, scale with the number of instantiations rather than with the number of shared assets. The city-generation comparison is also presented without a reproducible evaluation protocol. These gaps need to be addressed before the main claims can be fully accepted.","major_comments":[{"comment":"The factor-of-4 compression claim is not shown to be a consequence of procedural sharing. Table 3 (row 2) shows that the model with procedural code and clamp but without variance assets uses 87k Gaussians (PSNR 25.54), while the full model uses 291k (PSNR 27.68). Thus per-instantiation variance assets contribute roughly 204k of the 291k total, about 70% of the final model. Since Section 3.3 states that a separate variance asset is created for each instantiation of each base asset, the total Gaussian count should scale with the number of instantiations K, and the compression ratio relative to 3D-GS may collapse when per-instance variation is high—as Table 1's real-world result (500k vs. 384k, ~1.3x) already suggests. The paper does not report the base-asset/variance-asset split or the scaling of total Gaussians with K. The claim 'significantly reducing the model size by a factor of 4' should be qualified and supported by reporting this breakdown and a scaling analysis.","section":"Section 4.2, Table 1, and Section 3.3, Table 3"},{"comment":"The city-generation comparison is not reproducible. The paper does not describe how the baseline methods (Persistent Nature, SceneDreamer, CityDreamer, GaussianCity) were evaluated: which generated city assets or scenes were used, what camera trajectories were employed, and whether the depth and camera error metrics were computed in the same coordinate space and with the same rendering resolution as for Proc-GS. Since these baselines are generative models while Proc-GS assembles assets from captured buildings, the two tasks are not directly comparable unless the protocol is carefully matched. Please provide the full evaluation protocol for all methods, or reframe the comparison as illustrative rather than a quantitative head-to-head.","section":"Section 4.4, Table 4, and Section 4.1 metrics"},{"comment":"The real-world pipeline is not automatic. The Introduction says procedural code may be obtained 'manually or using an off-the-shelf segmentation model,' but the actual method in Appendix B involves manually annotating 2D procedural code for each facade and projecting it onto the mesh; no segmentation model is used in the presented pipeline. The Limitations section does acknowledge this, but the main text should state explicitly that real-world code extraction requires human annotation, since this directly affects the scalability claim for real-world scenes. Please describe the level of human involvement accurately in the main text.","section":"Section 3.2 and Appendix B"}],"minor_comments":[{"comment":"The quantitative comparisons report only averages over scenes, with no standard deviations or per-scene breakdown. The real-world PSNR difference between 3D-GS and Proc-GS is 0.19 dB, which may be within run-to-run or scene-to-scene variation; adding error bars or per-scene results would strengthen the 'comparable quality' claim.","section":"Table 1"},{"comment":"Figure 4 contains extraneous diagrams (labeled 'Sparse Voxel from SfM Points' and 'Neural Gaussian Prediction') that appear to be from a different method and do not correspond to the clamp operation described in the caption. Please replace these with a clean illustration of the Clamp Scale and Clamp Position operations.","section":"Figure 4"},{"comment":"The sentence 'significantly reducing the model size by a factor of 4' refers only to the synthetic benchmark; the following sentence mentions the lower real-world compression. Consider stating both numbers in one place to avoid overgeneralization.","section":"Section 4.2, first paragraph"},{"comment":"The building generator uses GPT-4o to convert raw procedural data into regular procedural code, but there is no evaluation of the correctness or robustness of this conversion. A small study (e.g., number of valid codes produced, human inspection results, or comparison to a deterministic rule-based converter) would help assess the reliability of the assembly stage.","section":"Section 3.4 and Appendix C"},{"comment":"The related work on inverse procedural modeling is mentioned, but the paper does not clearly position Proc-GS relative to methods that infer procedural rules from images or 3D models. A short discussion of how the proposed code extraction (from known procedural codes or manual annotation) differs from inverse procedural modeling would improve the context.","section":"Section 2.3"},{"comment":"Figure 1 uses 'ProcGS' while the rest of the paper uses 'Proc-GS'; please standardize. Also, the caption of Figure 4 is incomplete and should describe both subfigures accurately.","section":"Captions and typos"}],"recommendation":"major_revision","confidential_remarks":"The paper's central idea is timely and the dataset could be useful, but the compression claim needs a rigorous breakdown of base versus variance assets and a scaling analysis with respect to the number of instantiations. The city-generation comparison in Table 4 is currently a black box; the authors should either provide a detailed evaluation protocol or soften the claim. The real-world pipeline's manual annotation step is acknowledged in the limitations, but it should be presented honestly in the main text. I would also encourage the authors to release the dataset and code, as the project page is mentioned but no code/data link is given in the manuscript."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my take on Proc-GS. The core idea is genuinely new: constrain 3D-GS optimization with procedural code, share base assets across instances, and add a small per-instance variance asset. The dense-view results in Table 1 hold up — on the MatrixBuilding dataset they get 27.68 PSNR vs 27.54 for 3D-GS with 291k vs 1238k Gaussians. That's a real result. The sparse-view robustness is also striking: a 10x view cut gives them 23.11 PSNR vs 20.65 for 3D-GS. The bounding-box clamp is a simple trick that makes asset extraction editable, and the editing demos look convincing.\n\nNow the soft spots. The stress-test note is right that the 4x compression claim is not purely from sharing. The ablation shows that without variance assets you get 87k Gaussians at 25.54 PSNR, and adding variance brings you to 291k at 27.68. So variance assets are the majority of the final model. The paper should report the base/variance split and show how total count scales with the number of instantiations K. If it scales linearly with K, the factor-of-4 is a property of the low-diversity synthetic benchmark. The real-world numbers already hint at this: compression drops to 1.3x (500k vs 384k). The authors acknowledge this in Section 4.2, but they don't analyze it. That's a fair referee request, not a fatal flaw.\n\nThe bigger problems for me are the missing evaluation protocol for Table 4 and no released code or data. The city-generation comparison against CityDreamer and GaussianCity uses DE/CE metrics but doesn't say how the baselines were evaluated — same test views? same buildings? That comparison is almost meaningless without the protocol. And the real-world pipeline depends on manual annotation of procedural code, which is stated in Appendix B but not prominent in the abstract. The Limitations section does mention automating this as future work, so they're not hiding it, but the framing overstates automation.\n\nOverall: this is a useful, well-engineered paper that deserves a serious referee. The central rendering and compression claim on the synthetic dataset is solid as an empirical result. I'd ask for the variance/base split, scaling analysis, a documented evaluation protocol for Table 4, and a release of code and dataset. None of these are deal-breakers.","headline":"Solid engineering result with a real dataset, but the 4x compression claim needs the base/variance split and scaling analysis before it stands as advertised.","tokens_in":18086,"tokens_out":3756,"would_cite":true,"duration_ms":31459,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Proc-GS couples procedural building code with 3D Gaussian Splatting, cutting synthetic model size about 4x at comparable rendering quality and enabling editable, scalable city assembly.","keywords":["procedural modeling","3D Gaussian Splatting","building asset extraction","city generation","novel view synthesis","sparse-view reconstruction","procedural code","asset editing"],"falsifier":"Take a real facade and train Proc-GS twice, once with a correct hand-annotated procedural code and once with the same code whose repeat boundaries are shifted by one window position; if rendering quality and asset extraction are nearly identical, the procedural constraint is not doing the work the paper claims, whereas a clear degradation would confirm that the code must be exactly right.","tokens_in":17098,"feed_emoji":"🏙️","tokens_out":7289,"duration_ms":64043,"temperature":0.7,"pith_summary":"Proc-GS claims that buildings, which normally appear in 3D Gaussian Splatting as one undifferentiated cloud of Gaussians, can instead be reconstructed as a small set of shared base assets driven by a procedural code. Under this scheme, every repeated window or corner is a single asset instantiated many times, and the optimizer updates all instances synchronously; small per-instance variance assets absorb real differences. The result, the paper argues, is rendering quality on par with unconstrained 3D-GS while reducing the Gaussian count by about a factor of four on synthetic scenes, plus strong robustness when only a handful of training views are available. Because the code string itself controls assembly, editing and recombination become as simple as editing text, and the assets can be laid out into whole city blocks. For real scenes, the code is obtained by annotating facades and projecting onto meshes, so the method still depends on human input even though the asset extraction itself is automatic.","feed_headline":"Procedural building code shrinks 3D city models 4x","feed_subtitle":"Keeps rendering quality while turning repeated windows and corners into reusable, editable 3D assets.","key_machinery":"The load-bearing object is the procedural code string: a compact description such as \"L1_C1, (L1_W1)*, L1_C2\" that lists which base assets compose each level of a building. Each base asset is a set of 3D Gaussians defined in a local frame, with a bounding box, a pivot, and per-instantiation transformations; instantiating the code places copies of these Gaussians, and shared assets receive gradients from every copy. Per-instance variance assets, each also a small Gaussian set, let repeated copies differ without breaking sharing, and the Bbox Adaptive Clamp keeps Gaussians inside their asset boxes so extracted components can be recombined cleanly. This decomposition is what carries the compression, the sparse-view robustness, and the editability claims.","core_discovery":"The paper's central claim is that procedural code can be made the organizing structure of a 3D-GS reconstruction rather than an external add-on. Given a code string that says which base assets appear on each building level, Proc-GS initializes 3D Gaussians inside each asset's bounding box, instantiates the shared assets under rigid transformations, and optimizes the assembled building against rendering loss. The repeated assets are updated synchronously by gradients from all their appearances, and a separate variance asset per instance lets each copy deviate slightly in shape and color. With a bounding-box adaptive clamp to keep asset boundaries clean, this yields synthetic-scene results at 27.68 PSNR versus 27.54 for 3D-GS while using 291k Gaussians instead of 1,238k. The paper positions this as the first integration of procedural modeling with 3D-GS and as a route to editable, scalable city generation from both virtual and real captures.","pith_inferences":["The shared-asset prior is the real source of the compression: the method is betting that buildings are mostly repetitions, and the 4x model-size drop measures how much repetition exists in the dataset, not just the efficiency of the code representation.","A natural next step beyond the paper's scope is applying the same code-constrained Gaussian decomposition to other repeated structures, such as street furniture, industrial plants, or rows of trees, wherever a repeat pattern can be specified.","The variance-asset design suggests a testable prediction: on irregular real facades, most of the photorealism budget will be spent in the variance assets, so removing them should hurt real-scene PSNR more than synthetic-scene PSNR.","If procedural-code extraction ever becomes fully automatic, the pipeline converts ordinary drone photo sets into editable asset libraries, making the manual annotation step the main remaining bottleneck."],"forward_implications":["On the synthetic MatrixBuilding benchmark, Proc-GS reaches a PSNR of 27.68 versus 27.54 for 3D-GS while cutting the Gaussian count from 1,238k to 291k, a roughly 4x model-size reduction at comparable quality.","Reducing training views from 469 to 24 or 47, Proc-GS stays far ahead of 3D-GS (19.70 versus 16.93 PSNR at 24 views), because every repeated asset is reinforced by all of its instances.","Editing a building becomes a code edit: swapping window assets, changing repeat counts, and assigning different variance assets produce new buildings without retraining.","Assembling assets from different source buildings into one city, guided by a rule-based layout generator, yields 3D-consistent city views that score lower on camera and depth error than the generation baselines compared in the paper.","Real-world buildings can be converted into the same reusable asset form through mesh extraction, facade annotation, and projection, with only a slight drop in rendering accuracy (27.19 versus 27.38 PSNR against 3D-GS)."],"supporting_citations":[{"why":"Supplies the 3D-GS representation and differentiable rasterizer that Proc-GS constrains with procedural code; it is also the main baseline throughout the paper.","marker":"[22]"},{"why":"Provides the City Sample buildings whose procedural codes and multi-view renders form the MatrixBuilding dataset and the city-assembly workflow.","marker":"[1]"},{"why":"Sets the rendering protocol, including anti-aliasing and disabled motion blur, used to create dense multi-view images for the synthetic dataset.","marker":"[26]"},{"why":"Gives the 2D-GS geometry extraction used to build point clouds and meshes for real-world scenes before facade annotation.","marker":"[20]"},{"why":"Provides the planar-facade estimation that lets the paper locate and render facades for manual procedural-code annotation.","marker":"[48]"},{"why":"Converts raw level-by-level asset strings into regular procedural code with repeat groups, which the building generator then uses.","marker":"[21]"},{"why":"GaussianCity is a comparison baseline for city generation; the paper reports lower camera and depth error than it.","marker":"[44]"},{"why":"CityDreamer is a compositional city-generation baseline whose depth and camera error metrics the paper adopts and beats.","marker":"[45]"}],"fun_headline_variants":["Procedural code slashes 3D city Gaussian count 4x","One code string replaces 4x of 3D Gaussians in cities","Procedural 3D-GS builds cities 4x lighter","Editable city models from procedural Gaussian sharing","4x smaller 3D city assets via procedural code"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The method assumes a correct procedural code exists for every building, meaning someone must know, for each facade, which windows are the same asset and how they repeat; for real scenes the paper obtains this by manual facade annotation projected onto a mesh, so a wrong or approximate code would force visually different regions to share Gaussians and degrade both rendering and editing.","fun_headline_variants_meta":{"raw":{"variants":["Procedural code slashes 3D city Gaussian count 4x","One code string replaces 4x of 3D Gaussians in cities","Procedural 3D-GS builds cities 4x lighter","Editable city models from procedural Gaussian sharing","4x smaller 3D city assets via procedural code"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000594,"raw_usage":{"total_tokens":2756,"prompt_tokens":893,"completion_tokens":1863,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":509,"completion_tokens_details":{"reasoning_tokens":1774}},"tokens_in":509,"tokens_out":1863,"duration_ms":12571,"temperature":1.0,"reasoning_tokens":1774,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T18:37:19.413428+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a real facade and train Proc-GS twice, once with a correct hand-annotated procedural code and once with the same code whose repeat boundaries are shifted by one window position; if rendering quality and asset extraction are nearly identical, the procedural constraint is not doing the work the paper claims, whereas a clear degradation would confirm that the code must be exactly right.","supporting_citations":[{"cited_title":"3d gaussian splatting for real-time radiance field rendering","cited_arxiv_id":null,"evidence_quote":"Supplies the 3D-GS representation and differentiable rasterizer that Proc-GS constrains with procedural code; it is also the main baseline throughout the paper."},{"cited_title":"2, 3, 4, 6, 11","cited_arxiv_id":null,"evidence_quote":"Provides the City Sample buildings whose procedural codes and multi-view renders form the MatrixBuilding dataset and the city-assembly workflow."},{"cited_title":"Matrixcity: A large-scale city dataset for city-scale neural rendering and beyond","cited_arxiv_id":null,"evidence_quote":"Sets the rendering protocol, including anti-aliasing and disabled motion blur, used to create dense multi-view images for the synthetic dataset."},{"cited_title":"2d gaussian splatting for geometrically ac- curate radiance fields","cited_arxiv_id":null,"evidence_quote":"Gives the 2D-GS geometry extraction used to build point clouds and meshes for real-world scenes before facade annotation."},{"cited_title":"Finding good configurations of planar primitives in unorganized point clouds","cited_arxiv_id":null,"evidence_quote":"Provides the planar-facade estimation that lets the paper locate and render facades for manual procedural-code annotation."},{"cited_title":"Citydreamer: Compositional generative model of unbounded 3d cities","cited_arxiv_id":null,"evidence_quote":"CityDreamer is a compositional city-generation baseline whose depth and camera error metrics the paper adopts and beats."}],"review_version":1}