{"id":"81b2755a-6750-4d78-bee2-98ba57fb7344","arxiv_id":"2509.05963","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"Two small CNNs predict bloom brightness masks at 128x128 resolution, claiming 12-28% faster inference than a reimplemented Unity URP bloom shader with comparable MSE.","lead":"The paper trains two small neural networks to mimic the bloom post-processing effect and reports they run 12 to 28 percent faster than a shader-based bloom implementation. The speedup claim rests on a custom reimplementation of Unity's bloom shader rather than on measurements of the actual Unity engine.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Baseline performance measurement is not validated against actual Unity3D URP; 128x128 single-scene setup further undermines the headline speedup claim.","rationale":"The reader's weakest assumption is exactly the one I identify as most load-bearing: the Python/moderngl baseline's performance equivalence to Unity3D URP is asserted, not demonstrated. This is the crux of the paper's contribution, and the evidence does not support it. I agree with the reader's verdict. Additionally, the 128x128 resolution and single-scene training limit generalizability, but the baseline validation is the primary issue. The paper is an engineering exercise with plausible results, but as a scientific claim about outperforming Unity3D bloom, it is unsupported. Therefore the verdict should remain REJECT, or at most CONDITIONAL pending validation. I choose REJECT in agreement with the reader, since the central claim is the performance comparison and it is unsupported.","tokens_in":9041,"tokens_out":1511,"duration_ms":14087,"concrete_test":"Run an actual Unity3D URP build (same version and settings as Table 1) on the same GPU (NVIDIA L4) and measure bloom mask generation time using a GPU profiler or frame timing, at 128x128, for the same test dataset. Then compute the average time per frame and compare to Table 2's Unity3D Bloom average of 0.17253 ms. If the real Unity average is, say, below 0.14 ms, the claimed 28% speedup disappears; if it is close to 0.17253 ms, the baseline concern is resolved.","verdict_should_be":"REJECT","load_bearing_attack":"The central claim is that FastNBL and NBL beat the state-of-the-art Unity3D bloom implementation by 28% and 12% respectively (Section 4.4, Table 2). The speedup rests entirely on comparing against a Python/moderngl OpenGL reimplementation of the bloom algorithm, not the actual Unity3D URP implementation. Section 4.3 asserts the shader is a faithful reproduction ('This directly reflects Unity3D URP renderer bloom effect algorithm'), but provides no validation that its runtime is representative of Unity's engine. GPU performance depends heavily on engine-specific details (render pass management, framebuffer allocation, memory layout, shader compiler optimizations, driver behavior). A Python driver with moderngl and query objects is a fundamentally different execution context from Unity's native C++ renderer. The paper presents no timing data from Unity itself, no reasoning establishing equivalence, and no comparison of the two implementations' output beyond matching parameters. Without this, the 0.17253 ms baseline is unverified, and the claimed 28% speedup could vanish or reverse if the true Unity baseline differs. Compounding this, all performance and quality measurements are at 128x128 resolution (Section 3) on a single scene for the primary results, while the stated motivation is real-time rendering at 60-240 FPS, typically at much higher resolutions. The Conclusion explicitly notes the model does not support variable or higher resolutions. The quality claim also rests on an MSE threshold of 0.001 asserted as 'nearly indistinguishable' (Section 4.2) without perceptual validation, and the reported MSEs (0.00029 NBL, 0.00076 FastNBL) are against a single Unity configuration at a very low resolution. These issues are load-bearing because the paper's own contribution statement is precisely the performance comparison.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes two convolutional U-Net-style models, NBL and FastNBL, to generate bloom brightness masks in real time. The models are trained on 128×128 images to regress the brightness masks produced by Unity3D URP's bloom post-process. The authors report average MSE values of 0.00029 (NBL) and 0.00076 (FastNBL), and inference times of 0.14053 ms and 0.12352 ms, respectively, compared with 0.17253 ms for a Python/moderngl shader implementation that is claimed to reproduce the Unity URP bloom algorithm. From this they conclude that FastNBL is 28.4% faster and NBL is 12.1% faster than the Unity3D bloom implementation, while maintaining visually indistinguishable quality.","tokens_in":9375,"tokens_out":5162,"duration_ms":58881,"significance":"If the speed and quality claims were substantiated, a single-pass neural approximation of bloom could be a useful lightweight alternative in real-time rendering, freeing GPU time for other effects. The paper identifies a reasonable problem and the proposed architectures are simple and plausible. However, the central comparison is against a reimplementation rather than the actual engine, the quality criterion is an arbitrary MSE threshold without perceptual validation, and all measurements are at 128×128 on a single trained scene. As it stands, the paper does not provide sufficient evidence for its headline claims. No code or trained models are mentioned, limiting reproducibility.","major_comments":[{"comment":"The column labeled 'Unity3D Bloom' is actually a Python/moderngl OpenGL reimplementation of a three-pass bloom algorithm, not the Unity URP implementation. The paper asserts (Section 4.3, 'This directly reflects Unity3D URP renderer bloom effect algorithm') that the shader reproduces Unity's algorithm, but no validation is given that its runtime is representative of Unity's engine. GPU performance depends on render pass management, framebuffer allocation, shader compilation, and driver behavior, which differ between a Python/moderngl context and a native C++ engine. Without timing data from actual Unity URP or a rigorous equivalence argument, the claimed 28.4% and 12.1% speedups over 'state-of-the-art Unity3D Bloom' are unsupported.","section":"Section 4.3, Table 2"},{"comment":"The quality claim relies on an arbitrary threshold: 'MSE values below 0.001 are nearly indistinguishable from the ground truth images.' No perceptual experiment, PSNR, SSIM, or other standard metric is reported. The average MSE values (0.00029 and 0.00076) correspond to RMSE of roughly 0.017 and 0.028 on a [0,1] scale, i.e., several intensity levels on 8-bit images; calling this 'indistinguishable' is not justified. Additionally, although Section 4.1 mentions 'a variety of 3D scenes,' quantitative quality results are only reported for the single scene used for training; Figure 7 is illustrative and reports no error metric. The paper should report held-out-scene performance and use a perceptual or standard image-quality metric.","section":"Section 4.2"},{"comment":"All performance and quality measurements are performed at 128×128 resolution, and the conclusion explicitly states that the models are trained on a specific scene and do not support variable or higher resolutions. This is in tension with the stated motivation of real-time rendering at 60–240 FPS, which typically operates at much higher resolutions. The claimed speed advantage is therefore only demonstrated under conditions far from the target application. The authors should provide measurements at a more realistic resolution (e.g., 1080p) or clearly restrict the contribution to low-resolution settings.","section":"Sections 3 and 5"},{"comment":"The paper does not state how the training and test sets are partitioned. Section 4.1 says a test dataset of 5,000 paired images per scene was prepared, but no information is given about the number of training images or whether the test images are distinct from those used for training. Without a clear train/test split, the reported MSE values could reflect memorization rather than generalization. The authors should describe the data-generation protocol explicitly, including the number of training frames and their overlap with the test set.","section":"Section 4.1"}],"minor_comments":[{"comment":"Grammar/wording: 'Our solution generate' should be 'Our solution generates'; 'up to 30% faster' is not clearly tied to a specific baseline in the abstract.","section":"Abstract"},{"comment":"Several references are incomplete or malformed: [1] appears as just '2', [2] lacks a title, [5] is incomplete ('John O’Rorke Greg James'), [6] has no title, and [11] and [24] are informal URLs with no author/date. These need to be corrected for journal submission.","section":"References"},{"comment":"Typo: 'parametrs' should be 'parameters'.","section":"Table 1"},{"comment":"The text states 'All time measurements were performed using CUDA [15]' but the described shader baseline uses OpenGL moderngl and query objects. Please clarify which API/timing mechanism was used for which measurement.","section":"Section 4.3"},{"comment":"Only the NBL architecture is shown; FastNBL is described in text but not visualized. Adding a diagram for FastNBL or a combined figure would improve clarity.","section":"Figure 3"},{"comment":"The resolution notation is inconsistent ('128x128' vs '128×128'). Use a consistent format.","section":"Section 1.1 / 4.1"}],"recommendation":"major_revision","confidential_remarks":"The paper is an early preprint with several fundamental experimental gaps. The biggest issue is that the central speed claim compares against a Python/moderngl reimplementation, not the actual Unity URP engine; this is a load-bearing point that must be fixed by measuring the real engine baseline or providing a validated equivalence. The quality claim also needs stronger evidence. These are fixable in principle, but the current manuscript does not support its conclusions. If the authors cannot provide actual Unity timing, a reject may be more appropriate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Rafał, quick take on Neural Bloom. The central speedup claim doesn't hold as stated, because the “state-of-the-art Unity3D bloom” baseline is a Python/moderngl reimplementation whose runtime equivalence to Unity's actual renderer is asserted, not demonstrated. On GPUs, engine-level pass management, shader compilation, and memory layout can easily change timings by more than the claimed 28%. So the headline result is unproven.\n\nThat said, the paper does a few things honestly. It builds two compact CNNs that produce bloom masks in a single forward pass, properly measures inference with CUDA events and TorchScript, and—credit where due—the conclusion explicitly lists the limitations: single-scene training, fixed 128×128 input, and no guarantee of speed without further optimization. That transparency is more than many papers offer.\n\nThe soft spots are proportionate to the central claim. The quality metric is an arbitrary MSE threshold (0.001) without perceptual validation, and the p99 discussion is hand-wavy. The “variety of 3D scenes” in the abstract reduces to one extra scene with visual examples only. No code or data are available, so replication is impossible. The architectural label “U-Net-inspired” is generous for a three-layer encoder-decoder with no skip connections, but that's a labeling quibble.\n\nWho is this for? Someone cataloguing neural approaches to screen-space effects might cite it, but the numbers should not be taken at face value. It deserves a serious referee—the flaws are fixable, and the problem is relevant—but as submitted the performance comparison needs real Unity benchmarks and higher-resolution tests. If it goes to review, I'd ask for the Unity timing data and a perceptual evaluation. As is, I would not rely on the speedups.","headline":"Honest engineering with a load-bearing flaw: the speedup claim rests on an unvalidated Python reimplementation of Unity's bloom, so the headline numbers are not reliable as published.","tokens_in":9904,"tokens_out":2426,"would_cite":false,"duration_ms":27224,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A compact convolutional network can generate a bloom brightness mask in a single pass, matching Unity URP bloom visually while running about 28 percent faster than the shader baseline.","keywords":["bloom effect","real-time rendering","neural network","brightness mask","U-Net","post-processing","GPU performance","image regression"],"falsifier":"Run the same Unity URP bloom configuration inside a real Unity build on the same GPU, measure the bloom pass time, and compare it with fused NBL and FastNBL inference at the same 128x128 resolution; if native Unity bloom is already as fast as or faster than the networks, the central speed claim fails. A second check is to feed a scene not seen in training and measure brightness-mask MSE, since the paper reports only per-scene training results.","tokens_in":8939,"feed_emoji":"💡","tokens_out":4904,"duration_ms":51774,"temperature":0.7,"pith_summary":"This paper claims that a small convolutional network can replace the standard multi-pass bloom post-process in real-time rendering, producing a brightness mask in a single inference that looks nearly identical to Unity's URP bloom effect while taking less time. The authors train two U-Net-style networks, NBL and FastNBL, on paired 128x128 views of 3D scenes, using Unity-generated bloom masks as ground truth. On their benchmark, FastNBL averages 0.1235 ms per mask versus 0.1725 ms for a shader implementation that mirrors Unity's bloom algorithm, roughly 28 percent faster, while NBL is about 12 percent faster with slightly higher quality. The broader claim is that neural single-pass inference avoids the conditional branching and multi-sample blur passes of traditional bloom, freeing GPU time for other effects.","feed_headline":"Single-pass neural bloom beats Unity shader pipeline by 28 percent","feed_subtitle":"Two small U-Net variants match Unity URP bloom's look at 128x128 while cutting mask generation time.","key_machinery":"The load-bearing object is a shallow U-Net-style convolutional network trained to regress the bloom brightness mask from the scene view. Its encoder-decoder structure extracts spatial features at multiple scales and returns an image-sized mask in one pass, replacing the traditional prefilter, downsample-blur, and upsample pyramid. The speed difference comes from replacing many texture samples and conditional threshold branches with a fixed set of convolution operations; the two variants trade a few operations for quality via dilated and grouped convolutions.","core_discovery":"The central claim is that the bloom effect—normally a sequence of thresholding, downsampled Gaussian blurs, and upsampling passes—can be approximated by a shallow encoder-decoder network that directly outputs the brightness mask. The paper identifies two working configurations: NBL, using a convolution-batch-norm-ReLU encoder and decoder, and FastNBL, using dilated convolutions and grouped convolutions for fewer operations. Both are trained per scene with MSE loss against Unity URP bloom output and then optimized by fusing layers and compiling the model. On 5,000 test images per scene, NBL reaches an average MSE of 0.00029 and FastNBL 0.00076, both below the authors' threshold of 0.001 for v","pith_inferences":["The speed comparison is made at 128x128; at production resolutions the convolution cost grows with pixel count while the shader's pyramid blur uses downsampled buffers, so the observed margin may shrink or reverse—the paper does not measure this.","The models are trained per scene, so a practical deployment would need either runtime adaptation or a general model; the paper lists this as a limitation, implying the natural next experiment is training one network on many scenes and measuring cross-scene MSE.","The paper does not measure temporal stability across frames; a neural mask that flickers would fail in motion even if per-frame MSE is low, and this is a plausible risk for a single-pass regressor.","The same architecture could be tested on other branch-heavy, multi-pass post-effects such as depth-of-field or motion blur; the authors state this direction but provide no results yet."],"forward_implications":["If the claim holds, a game engine could request a bloom mask from network inference on dedicated tensor cores, freeing texture units for other rendering work in the same frame.","A single-pass neural bloom would eliminate warp divergence from threshold branching, making frame times more predictable than the reference shader, as NBL's lower variance suggests.","The same per-scene training recipe should let a developer bake a scene-specific bloom approximation that is faster than the engine's own shader on that scene.","Because quality is measured against Unity URP bloom masks, the method inherits the look of that reference effect rather than introducing a new physically based model.","The reported 12-28 percent speedup is demonstrated at 128x128 resolution, so production integration would first need to confirm the margin at higher resolutions."],"supporting_citations":[{"why":"Supplies the encoder-decoder U-Net architecture that both network variants are built on.","marker":"[19]"},{"why":"Defines the Unity URP bloom effect, its parameters, and the algorithm the baseline shader reproduces.","marker":"[22]"},{"why":"Provides the Python OpenGL wrapper used to implement and time the shader-based baseline.","marker":"[4]"},{"why":"Supplies the Gaussian-blur cost model that motivates the neural alternative.","marker":"[8]"},{"why":"Supplies the compiled model format used in the neural inference timing measurements.","marker":"[17]"},{"why":"Identifies the engine whose bloom implementation is treated as the industry-standard baseline.","marker":"[21]"},{"why":"Demonstrates that CNNs can perform screen-space shading, providing precedent for neural post-processing.","marker":"[14]"},{"why":"Shows that CNNs are viable for real-time image upsampling, supporting the general feasibility of neural real-time effects.","marker":"[25]"}],"fun_headline_variants":["Single-pass neural bloom cuts render time by 28%","Neural bloom matches Unity quality 28% faster","FastNBL: neural bloom at 28% less compute","Deep learning swap makes bloom 28% quicker","Neural bloom: one pass, 28% faster than URP"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The central speedup rests on the claim that the Python/moderngl shader implementation accurately represents Unity's actual URP bloom performance; the paper asserts this equivalence without timing Unity itself, so if the shader is slower than the real engine the reported 12-28 percent gains are not against the claimed baseline.","fun_headline_variants_meta":{"raw":{"variants":["Single-pass neural bloom cuts render time by 28%","Neural bloom matches Unity quality 28% faster","FastNBL: neural bloom at 28% less compute","Deep learning swap makes bloom 28% quicker","Neural bloom: one pass, 28% faster than URP"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000348,"raw_usage":{"total_tokens":1751,"prompt_tokens":767,"completion_tokens":984,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":511,"completion_tokens_details":{"reasoning_tokens":902}},"tokens_in":511,"tokens_out":984,"duration_ms":9851,"temperature":1.0,"reasoning_tokens":902,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T04:43:59.560846+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same Unity URP bloom configuration inside a real Unity build on the same GPU, measure the bloom pass time, and compare it with fused NBL and FastNBL inference at the same 128x128 resolution; if native Unity bloom is already as fast as or faster than the networks, the central speed claim fails. A second check is to feed a scene not seen in training and measure brightness-mask MSE, since the paper reports only per-scene training results.","supporting_citations":[{"cited_title":"U-net: Convolutional networks for biomedical image segmentation","cited_arxiv_id":null,"evidence_quote":"Supplies the encoder-decoder U-Net architecture that both network variants are built on."},{"cited_title":"https : / / docs","cited_arxiv_id":null,"evidence_quote":"Defines the Unity URP bloom effect, its parameters, and the algorithm the baseline shader reproduces."},{"cited_title":"readthedocs","cited_arxiv_id":null,"evidence_quote":"Provides the Python OpenGL wrapper used to implement and time the shader-based baseline."},{"cited_title":"Springer, 2001","cited_arxiv_id":null,"evidence_quote":"Supplies the Gaussian-blur cost model that motivates the neural alternative."},{"cited_title":"Torchscript: A scripting language for pytorch models, 2019","cited_arxiv_id":null,"evidence_quote":"Supplies the compiled model format used in the neural inference timing measurements."},{"cited_title":"Version 2024.1.0, available athttps://unity.com/","cited_arxiv_id":null,"evidence_quote":"Identifies the engine whose bloom implementation is treated as the industry-standard baseline."},{"cited_title":"Deep Shading: Convolutional Neural Networks for Screen-Space Shading","cited_arxiv_id":"1603.06078","evidence_quote":"Demonstrates that CNNs can perform screen-space shading, providing precedent for neural post-processing."},{"cited_title":"Neural supersampling for real-time rendering.ACM Trans","cited_arxiv_id":null,"evidence_quote":"Shows that CNNs are viable for real-time image upsampling, supporting the general feasibility of neural real-time effects."}],"review_version":1}