{"id":"3a9542c5-e67d-4e1b-ade5-115544d23f2b","arxiv_id":"2507.11794","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"A WebGPU mass-spring cloth simulator runs at 60fps for hanging cloth up to 640K nodes and handles collisions with a 100K-triangle model at 30fps in a benchmark.","lead":"This paper benchmarks a WebGPU-based mass-spring cloth simulation against WebGL, reporting faster frame rates at high resolutions. It also tests collision handling with 3D models and provides the source code on GitHub.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Collision experiment numbers are internally inconsistent with the stated brute-force triangle-pair workload; the claimed 30fps at 4K cloth nodes vs. 100K-triangle Dragon requires clarification or correction.","rationale":"The reader identified the same load-bearing flaw and I agree with their judgment that the brute-force collision workload versus stated fps is the key credibility issue. My recommendation is CONDITIONAL rather than REJECT because the central qualitative claim (WebGPU outperforms WebGL and can handle substantial real-time collision workloads) is plausible and the paper provides public source code that could verify the workload; the right outcome is to require the authors to demonstrate the actual workload before the quantitative limits are accepted. The paper has independent support in the form of a public repository and a clearly described spring-centric approach, but the missing workload measurement and the algorithm ambiguity prevent verification of the strongest claim. I emphasize an internal inconsistency rather than an external credibility judgment: the paper never states a broad-phase culling scheme, yet the reported fps numbers imply either a much smaller number of intersection tests or a very aggressive GPU optimization that is not documented. The concrete check of instrumenting the collision dispatch settles the dispute deterministically; therefore the verdict should be conditional on that check, not an outright rejection.","tokens_in":9225,"tokens_out":1651,"duration_ms":17614,"concrete_test":"Run the published repository (https://github.com/nakjun/Cloth-Simulation-WebGPU) with the Dragon model and a 4K-node cloth, and instrument the compute pass to count the number of triangle-pair intersection tests and report the per-frame time of the collision dispatch separately from rendering. If the count is ~7.9e8 per frame at 30fps, the claimed performance is real; if it is lower by orders of magnitude (e.g., due to bounding-volume culling or a smaller effective workload), the paper's stated brute-force method is not what was measured, and the headline claim needs revision.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central performance claim in Section 4.2 is that WebGPU sustains 30fps for a 4K-node cloth colliding with a 100K-triangle Dragon model under the stated algorithm. Section 3 says collision detection uses triangle-triangle intersection as an extended Moller-Trumbore test between cloth triangles and surface triangles, with Algorithm 2 then applying response per cloth vertex. The reader's weakest_assumption is that this is a brute-force all-pairs test without spatial acceleration, and Section 5 lists collision culling as future work. If the actual published code uses a different, accelerated collision scheme, the claim may be credible but the paper's stated method is misleading; if the code really does all-pairs, the frame-rate numbers are implausible. The paper provides no error bars, no timing breakdown, and no per-frame workload measurement, so the reported fps values cannot be independently checked from the text. Additionally, in Section 3 the algorithm is described as 'edge-triangle' (S to E with triangle V0,V1,V2) while the same section calls it 'triangle-triangle' and Algorithm 2 applies response per vertex, which is an ambiguity that materially affects the workload estimate: a 4K-node grid has roughly 2*N - 2*sqrt(N) = 7922 cloth triangles; all-pairs against 100K triangles is ~7.9e8 intersection tests per frame, which would not run at 30fps on an RTX 4070 Ti in WebGPU without broad-phase culling or early-out bounding tests. The load-bearing issue is thus that the paper does not demonstrate that the workload it claims to run is the workload that was benchmarked; the correctness of the headline limit depends on this.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a WebGPU-based cloth simulation system using a mass-spring model with spring-centric compute shaders, collision detection via an extended Möller–Trumbore test, and per-vertex collision response. It reports two sets of experiments: (1) a hanging-cloth comparison between WebGPU and WebGL, claiming that WebGPU maintains 60fps with up to 640K cloth nodes while WebGL struggles beyond 10K nodes; and (2) a collision benchmark between cloth and three 3D surface models (Sphere, Armadillo, Dragon), claiming that WebGPU sustains 30fps for a 4K-node cloth against a 100K-triangle Dragon model. The authors release their source code on GitHub.","tokens_in":9533,"tokens_out":7513,"duration_ms":86455,"significance":"If the performance results are reproducible, the paper provides a useful data point for WebGPU's applicability to real-time physics simulation in the browser, and the release of source code is a positive contribution. The comparison with WebGL, however, conflates API differences with implementation differences, and the collision experiment's workload as described is inconsistent with the reported frame rates. As written, the quantitative claims cannot be accepted without substantial clarification and additional measurement detail.","major_comments":[{"comment":"The reported 30fps for a 4K-node cloth colliding with a 100K-triangle Dragon model is inconsistent with the collision pipeline as described. Section 3 states \"When collision check for all triangle pairs is completed\" and Section 5 lists collision culling as future work, implying brute-force all-pairs testing. A 4K-node regular grid contains roughly 8,000 triangles and roughly 12,000 springs; all-pairs edge-triangle tests would require approximately 0.8–1.2 billion intersection tests per frame. At 30fps this is 2.4–3.6×10^10 tests per second, far beyond the capabilities of an RTX 4070 Ti for Möller–Trumbore-style tests without broad-phase acceleration. The authors must clarify whether a spatial acceleration structure, bounding-box prefilter, or early-out is actually used in the measured code. If none is used, the fps values need to be re-measured and reported together with a per-frame timing breakdown.","section":"Section 4.2 / Section 3"},{"comment":"The performance measurements lack the statistical and methodological detail expected for a benchmark claim. There are no error bars, no number of repeated runs, no statement about vsync or frame pacing, no warm-up procedure, and no description of how the fps number is computed (e.g., average over N frames, 99th percentile, or instantaneous). Moreover, the WebGL baseline uses the Three.js library while the WebGPU implementation appears to be a custom implementation; this conflates API-level differences with library and implementation overhead. A fair comparison would use comparable implementations or, at minimum, report the implementation details for both.","section":"Sections 4.1 and 4.2"},{"comment":"The collision detection algorithm is described inconsistently. The text first says the system employs \"triangle-triangle intersection,\" but the Extended Möller–Trumbore Process is then specified for an edge with endpoints S and E against a triangle with vertices V0, V1, V2, and Algorithm 2 applies the response per cloth vertex. These are different workloads with different computational costs and different response aggregation. The paper must state precisely which primitive pairs are tested per thread and how the per-vertex response is accumulated; otherwise the experiment cannot be reproduced and the claimed frame rates cannot be assessed.","section":"Section 3"},{"comment":"The scaling behavior of the collision experiments is not reported in full. The text gives only selected points (the resolution at which 30fps is achieved and the maximum resolution before performance collapses), with no fps-versus-resolution curves or tables for the Sphere, Armadillo, and Dragon models. Reporting the complete series, including standard deviations, is necessary both to support the \"limits of real-time\" claim and to allow readers to verify the monotonic degradation described in the text.","section":"Section 4.2"}],"minor_comments":[{"comment":"The phrase \"between 4K and 100k cloth node models\" is ambiguous; the experiments use 4K and up to 65.5K cloth nodes, not 100K.","section":"Abstract"},{"comment":"There are several typos: \"Evnrionment\" in Section 4.1, \"Haning\" in Figure 6, and \"T able\" in the table captions.","section":"Section 4.1 / Figure 6"},{"comment":"The sentence \"If the cloth model resolution exceeded this threshold, this was generated, the simulation performance degraded to the extent...\" is ungrammatical and should be rewritten.","section":"Section 5"},{"comment":"The word \"Additionaly\" should be \"Additionally.\"","section":"Section 2.2"},{"comment":"Reference [1] appears truncated (the URL is cut off), and several entries lack complete information.","section":"References"},{"comment":"The paper should specify whether the reported fps include rendering or only the simulation/compute pass, since the WebGL comparison may be dominated by rendering cost rather than simulation.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The central issue is the collision-experiment inconsistency: as described, the algorithm cannot plausibly achieve the reported frame rates. I would ask the editor to require, at revision, either a corrected description of the actually implemented collision pipeline (including any broad-phase steps) or a re-run of the experiment with a per-frame timing breakdown. The source code link may help verification, but the manuscript itself must be self-contained on this point."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The headline: this is a modest but honest benchmark paper that does one new thing—comparing a mass-spring cloth simulator with collision response on WebGPU against WebGL—and it does it with released code. The hanging-cloth result (60fps up to 640K nodes on WebGPU vs. WebGL falling off the real-time cliff around 10K nodes) is plausible and consistent with prior WebGPU-vs-WebGL comparisons. The source code is a real asset.\n\nWhat it does well: straightforward, reproducible application of standard methods (mass-spring, Möller–Trumbore intersection) to a new API, and the performance limits it reports are the sort of engineering data the web-graphics community needs. The spring-centric force accumulation with atomics is a reasonable choice for volumetric objects.\n\nNow the soft spots, and there is one load-bearing one. The collision experiment is described as \"triangle-triangle intersection,\" but the extended Möller–Trumbore process given in Section 3 is actually an edge-triangle intersection, and Algorithm 2 applies response per vertex. That ambiguity changes the workload by a large factor. With a brute-force all-pairs implementation—the paper explicitly lists BVH and collision culling as future work—a 4K-node cloth against a 100K-triangle Dragon means roughly 8e8 intersection tests per frame. The claim of 30fps on an RTX 4070 Ti under that workload is not obviously impossible, but it is aggressive enough that the paper needs to show the actual kernel, a timing breakdown, and error bars. None of that is present. There are no error bars anywhere, no description of how fps was measured, and no frame-counter screenshots. The WebGL baseline uses Three.js, so the comparison is library-vs-API, not a clean API-vs-API benchmark.\n\nAlso, the analysis of why performance drops is thin: the paper jumps from fps numbers to \"need culling\" without quantifying where the time goes.\n\nWho this is for: developers building web-based cloth simulations and people tracking WebGPU's maturity. Not a research breakthrough, but a useful engineering data point.\n\nRecommendation: I wouldn't publish this as-is, but I would send it out rather than desk reject. The code is available and the claims are testable; a serious referee could run it or ask for the missing details. If the collision numbers survive contact with the actual kernel, it's an acceptable short paper. If they don't—or if the authors can't clarify the algorithm—it's a reject. So: send to review, but the bar for acceptance should be \"verify the numbers.\"","headline":"Modest but honest WebGPU-vs-WebGL cloth benchmark that stumbles on a load-bearing ambiguity in the collision workload, making the headline fps claims unverifiable from the text.","tokens_in":10078,"tokens_out":5449,"would_cite":false,"duration_ms":60319,"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":"WebGPU keeps a mass-spring cloth simulation at 60fps up to 640K nodes, while WebGL falls below real time past 10K.","keywords":["Real-Time Simulation","Cloth Simulation","WebGPU","WebGL","Mass-Spring Method","Collision Detection","Compute Shaders","Möller-Trumbore"],"falsifier":"Instrument the WebGPU pipeline to time only the collision-detection dispatch for the 4K-node cloth against the 100K-triangle Dragon model and add a counter for dispatched edge-triangle pairs. If the pair count is less than (cloth edges × 100,000) or the collision pass alone exceeds about 33ms per frame on the reported RTX 4070 Ti, the all-pairs 30fps claim does not hold as stated.","tokens_in":9057,"feed_emoji":"🧵","tokens_out":9101,"duration_ms":96067,"temperature":0.7,"pith_summary":"The paper sets out to show that WebGPU, the browser graphics API with compute-shader support, can carry real-time cloth simulation at resolutions that WebGL cannot reach. In a hanging-cloth benchmark, a mass-spring solver runs at 60 frames per second with up to 640,000 nodes on WebGPU, whereas WebGL becomes non-interactive beyond roughly 10,000 nodes. The authors then push WebGPU to its limit in collision scenarios: a 4,000-node cloth hitting a 100,000-triangle model sustains 30fps, but higher cloth resolutions collapse to a few frames per second. The point is that WebGPU moves web graphics from rendering-only to general-purpose GPU computation, which matters for browser-based games, virtual try-on, and AR/VR where users cannot install software.","feed_headline":"WebGPU cloth sim holds 60fps at 640K nodes","feed_subtitle":"WebGL drops below real time past 10K nodes; WebGPU's compute shaders open high-resolution physics to the browser.","key_machinery":"The mechanism that carries the argument is the WebGPU compute pipeline running a spring-centric mass-spring solver. One thread per spring computes $F = k(\\|d\\| - L)$ plus a damping term along the spring direction, then uses atomic additions to accumulate equal-and-opposite forces on the two endpoint nodes, so no node-level serialization is needed. Collision detection uses an extended Möller-Trumbore test, a segment-triangle intersection routine that reports where along a cloth edge the surface triangle is hit, and collision response stores per-vertex response directions in atomic buffers and applies their average when updating positions. This combination lets a browser execute the per-spring physics and per-edge collision workload in parallel, which is exactly what WebGL's rendering-only shader model cannot do.","core_discovery":"The paper's central claim is that WebGPU's compute pipeline, combined with a spring-centric mass-spring solver, makes high-resolution cloth simulation practical in a web browser. Each spring is handled by one GPU thread, which computes Hooke's law and damping forces and accumulates the result with atomic writes into a temporary force buffer; collision detection then applies an extended Möller-Trumbore edge-triangle intersection test, and collision response averages the detected directions before updating positions. With this pipeline the paper reports 60fps at 640K nodes in the gravity-only hanging scene, and 30fps when a 4K-node cloth collides with the 100K-triangle Dragon model. The same experiments expose the current limit: collision handling without spatial acceleration drops to 3.05fps at 65.5K nodes against the Armadillo model and 7.47fps at 16.3K nodes against the Dragon model.","pith_inferences":["The paper does not claim it, but the same compute-shader force-accumulation pattern should port to position-based dynamics or projective dynamics, since those solvers also reduce to parallel constraint updates; the authors list these as future work.","The paper attributes the 640K-node ceiling to a 128MB buffer allocation limit; if so, that ceiling is a memory-cap artifact rather than a measured throughput limit, and larger buffers or chunked accumulation could raise it on other devices.","A reader should not generalize the 30fps collision result to other cloth topologies: the all-pairs workload scales with the number of cloth edges multiplied by the number of surface triangles, so a mesh with more springs per node will hit the same performance wall at lower node counts."],"forward_implications":["Browser-based cloth applications can run at full frame rate with roughly 640K mass-spring nodes, a resolution that previously required native installs.","Equal 60fps performance needs about 160 times fewer nodes on WebGL than on WebGPU for this workload.","Real-time collision with high-detail surfaces is attainable only at low cloth resolution (4K nodes for the 100K-triangle model), so visual detail and real-time response must still be traded off.","Without collision culling, the brute-force approach hits a wall: 65.5K cloth nodes against 50K triangles runs at 3.05fps, making acceleration structures the obvious next step."],"supporting_citations":[{"why":"supplies the WebGPU architecture background, including compute shaders, that the implementation relies on","marker":"[10]"},{"why":"foundational cloth simulation work that motivates the mass-spring pipeline structure","marker":"[17]"},{"why":"defines the mass-spring model used for cloth forces and deformation constraints","marker":"[20]"},{"why":"fast mass-spring simulation basis for the parallel spring-centric force computation","marker":"[21]"},{"why":"triangle-triangle intersection test that the collision detection extends","marker":"[30]"},{"why":"ray-triangle intersection algorithm that the extended Möller-Trumbore edge-triangle test is based on","marker":"[31]"},{"why":"Euler integration used for predicting the cloth's next position each frame","marker":"[32]"}],"fun_headline_variants":["WebGPU cloth sim hits 60fps at 640K nodes","Browser cloth simulation at 640K nodes, 60fps","WebGPU brings high-res cloth sim to the browser","Compute shaders power real-time cloth in WebGPU","WebGPU beats WebGL for high-resolution cloth simulation"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the collision loop in Section 4.2 really tests every cloth edge against every surface triangle each frame with no spatial acceleration, because the reported 30fps otherwise implies more edge-triangle tests per second than the hardware plausibly sustains.","fun_headline_variants_meta":{"raw":{"variants":["WebGPU cloth sim hits 60fps at 640K nodes","Browser cloth simulation at 640K nodes, 60fps","WebGPU brings high-res cloth sim to the browser","Compute shaders power real-time cloth in WebGPU","WebGPU beats WebGL for high-resolution cloth simulation"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000284,"raw_usage":{"total_tokens":1683,"prompt_tokens":963,"completion_tokens":720,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":579,"completion_tokens_details":{"reasoning_tokens":637}},"tokens_in":579,"tokens_out":720,"duration_ms":7230,"temperature":1.0,"reasoning_tokens":637,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T17:00:45.895921+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Instrument the WebGPU pipeline to time only the collision-detection dispatch for the 4K-node cloth against the 100K-triangle Dragon model and add a counter for dispatched edge-triangle pairs. If the pair count is less than (cloth edges × 100,000) or the collision pass alone exceeds about 33ms per frame on the reported RTX 4070 Ti, the all-pairs 30fps claim does not hold as stated.","supporting_citations":[{"cited_title":"ACM Transactions on Graphics (TOG) 32(6), 1–7 (2013)","cited_arxiv_id":null,"evidence_quote":"fast mass-spring simulation basis for the parallel spring-centric force computation"},{"cited_title":"Journal of Graphics Tools 2(2), 25–30 (1997)","cited_arxiv_id":null,"evidence_quote":"triangle-triangle intersection test that the collision detection extends"},{"cited_title":"ACM SIGGRAPH 2022 Courses, 1–184 (2022)","cited_arxiv_id":null,"evidence_quote":"supplies the WebGPU architecture background, including compute shaders, that the implementation relies on"},{"cited_title":"In: Proceedings of the 25th Annual Conference on Computer Graphics and Interactive Techniques, pp","cited_arxiv_id":null,"evidence_quote":"foundational cloth simulation work that motivates the mass-spring pipeline structure"},{"cited_title":"In: Graphics Interface, pp","cited_arxiv_id":null,"evidence_quote":"defines the mass-spring model used for cloth forces and deformation constraints"},{"cited_title":"In: ACM SIGGRAPH 2005 Courses (2005)","cited_arxiv_id":null,"evidence_quote":"ray-triangle intersection algorithm that the extended Möller-Trumbore edge-triangle test is based on"},{"cited_title":"In: Proceedings of 2012 2nd International Conference on Computer Science and Network Technology, pp","cited_arxiv_id":null,"evidence_quote":"Euler integration used for predicting the cloth's next position each frame"}],"review_version":1}