{"id":"c3d04eda-ef16-4979-bd67-824c74bf4943","arxiv_id":"2508.17172","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"VROOM shows that MonST3R, with the bottom half of the frame masked and the video split into short chunks, can partially reconstruct the Monaco circuit's shape and the car's path, but the full loop does not close.","lead":"This paper builds a pipeline that turns a racecar's onboard video into a rough 3D model of a Formula 1 circuit, using an existing reconstruction model plus masking and chunking tricks. A generalist might read it as a test of how far current 3D vision tools go on high-speed broadcast footage that was never meant for reconstruction.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Fig. 10's 'very close to ground truth' claim is uncheckable because the alignment between MonST3R's scale-ambiguous pointmaps and the track map is unspecified; without an error metric, the central feasibility evidence is not quantified.","rationale":"This is an honest, scoped feasibility study. The authors explicitly state that the loop is not closed, the loop-closure modification was unfinished, and the results are partial. The provided code link is real evidence, and the qualitative figures suggest meaningful progress. The reader's CONDITIONAL verdict is appropriate. The single most load-bearing weakness is not the lack of loop closure but the unverified comparison underlying the strongest positive claim: Fig. 10's 'very close to ground truth.' Because MonST3R's output is up to scale and in an arbitrary coordinate frame, any comparison to a real-world map requires an alignment step. The paper does not specify that step, so the reader cannot distinguish a genuinely close reconstruction from one that was manually fit to look close. My proposed test—fix scale from known track width, estimate only rigid alignment, and report metric error—would settle whether the local reconstruction is really close. It also addresses the related concern that preprocessing was tuned on the same footage, since a well-aligned local result would still be stronger evidence if it generalizes to the failure cases shown in the appendix. I do not recommend REJECT: the claims are modest, the limitations are openly stated, and the missing measurement is fixable. UNCHANGED preserves the conditional verdict while giving the authors a concrete path to ACCEPT.","tokens_in":5723,"tokens_out":4785,"duration_ms":59139,"concrete_test":"Re-extract the raw point cloud used for Fig. 10 before alignment. Fix scale using the known Monaco track width (~7–8 m), estimate only rotation+translation (e.g., ICP from the official track centerline), and report mean/95th-percentile distance in meters between transformed reconstruction and the reference map. If residual is ≤ 1 track width, 'very close' is supported; if several track widths, the claim is unsupported. Additionally, report the original alignment parameters (similarity vs. rigid; if scale was free) to determine whether absolute scale was ever validated.","verdict_should_be":"UNCHANGED","load_bearing_attack":"MonST3R outputs per-frame pointmaps in an arbitrary reference frame with unknown scale, so any overlay with the official track map (Sec. 4.2, Fig. 10) requires estimating a similarity transform (scale, rotation, translation). The paper never states how this transform was obtained, nor does it report a distance error after alignment. If the transform was chosen to maximize visual overlap, then 'very close to ground truth' is partly an artifact of the fit. This matters because the paper's positive claim—that VROOM 'partially recovers track and vehicle trajectories'—rests on this qualitative comparison. The failure to close the loop (Fig. 9) is honestly acknowledged and is not the issue. Preprocessing choices were tuned on the same footage, which is a secondary concern; the missing alignment definition is more load-bearing because it makes the evidence non-reproducible.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces VROOM, a preprocessing and reconstruction pipeline for recovering 3D track geometry and vehicle trajectory from monocular onboard Formula 1 footage. Using 2023 Monaco Grand Prix onboard videos, the pipeline downsamples video to 512x144 at 24 FPS, applies a bottom-half masking heuristic, chunks the video into approximately 5-second overlapping segments that are split on straight sections, and runs MonST3R per chunk. Per-chunk reconstructions are stitched by using one-frame overlaps to align camera extrinsics. The authors compare three methods—DROID-SLAM, AnyCAM, and MonST3R—and report that MonST3R gives the best results. They qualitatively show that individual chunk reconstructions are 'very close' to the track map (Fig. 10), while the full stitched track fails to close the loop (Fig. 9). The manuscript openly states that a cross-chunk global bundle adjustment step was not completed. The paper includes a project page and code repository.","tokens_in":5863,"tokens_out":3837,"duration_ms":40592,"significance":"If the local reconstruction claim is validated, the paper demonstrates a practical preprocessing recipe that makes an existing feed-forward dynamic-scene reconstruction model (MonST3R) usable on challenging onboard F1 footage. The authors are transparent about the unfinished loop-closure step and about the exploratory nature of the masking and chunking choices; they also release code and a project page, which are strengths. However, the central evidence is qualitative and rests on an unspecified alignment between MonST3R's scale-ambiguous pointmaps and the reference track map. No numerical metric (e.g., ATE, RPE, or point-cloud error) is reported anywhere, and all preprocessing hyperparameters were tuned on the same test video. The stated feasibility claim is therefore plausible but not yet adequately supported. The stress-test concern about Fig. 10's unverifiable alignment is a real and load-bearing issue, not a peripheral one.","major_comments":[{"comment":"The claim that each individual segment's reconstruction is 'very close to the ground truth map' is not reproducible because the alignment between MonST3R's output and the track map is unspecified. MonST3R outputs pointmaps in an arbitrary reference frame with unknown scale; overlaying them with an external map requires estimating a similarity transform (scale, rotation, translation). The paper does not state how this transform was obtained or report any post-alignment distance error. If the transform was fit to maximize visual overlap, 'very close' is partly an artifact of the fit. Since this is the central positive result, please specify the alignment method concretely and report numerical error, e.g., point-to-track-centerline distance after alignment, or ATE/RPE for the camera trajectory.","section":"§4.2, Fig. 10"},{"comment":"All preprocessing hyperparameters (bottom-half mask fraction, chunk length and overlap, downsampled resolution 512x144, 24 FPS, and the 12 FPS lower bound) were selected by experimentation on the same footage used for the final qualitative evaluation. Section 3.2.1 states the choices were made 'by testing against several, short 5 second chunks of the original video.' This introduces overfitting risk: the apparent success in Fig. 10 may depend on choices that do not transfer to other laps, circuits, or camera mounts. Please add a sensitivity analysis for at least the mask fraction and chunk length, or validate on an unseen onboard sequence, to support the claim of feasibility beyond this single video.","section":"§3.2, §4"},{"comment":"The manuscript contains no quantitative evaluation. There is no ATE/RPE for the camera trajectory, no point-cloud error against a reference model, and no quantitative comparison among DROID-SLAM, AnyCAM, and MonST3R. Even for a feasibility study, a single numerical measure (e.g., trajectory error after alignment, or fraction of track centerline reconstructed within a threshold) is necessary to substantiate 'partial recover[y] of track and vehicle trajectories.' The absence of metrics also prevents other researchers from comparing against this work. Please add at least one objective error metric, and ideally report it for each test chunk as well as for the stitched trajectory.","section":"§4 (overall)"},{"comment":"The stitching procedure is described only as 'utilized the overlap between chunks in order to transform one chunk’s camera extrinsics into another camera’s reference frame.' Because each MonST3R chunk is scale-ambiguous and the overlap is only 1 frame, it is unclear how the similarity transform is computed, how scale is propagated across chunks, and how drift is accumulated. This is load-bearing for the claimed 'single camera trajectory' and for the full track reconstruction in Fig. 9. Please provide the exact algorithm (e.g., Umeyama alignment on common points, or pose graph optimization), or state explicitly that the current stitching is a simple frame-to-frame transform and that this is a known limitation.","section":"§3.3.3"}],"minor_comments":[{"comment":"Spelling is inconsistent: 'Monst3r' and 'MonST3R' are used interchangeably (e.g., abstract vs. §3.3.3). 'Monaca' should be 'Monaco' in §5. Fix these before final submission.","section":"Throughout"},{"comment":"The phrase 'the second sector s (turns 5-12)' has a stray 's'. Also, the text says each video is 'about 80 seconds long,' but later refers to 'the first lap' and 'the entire race'; clarify which portion of the race is used and how the 20 onboard videos are sampled.","section":"§1.1"},{"comment":"Figure 4 and Figure 5 captions are terse ('Masking Car', 'Masking Bottom Half'). Please describe what each mask covers and the exact pixel-region operation used.","section":"§3.2.2"},{"comment":"The description of 'smarter chunking' (splitting only on straight segments) is qualitative. How is a 'straight' detected? State the criterion (e.g., steering angle threshold, track map knowledge, or manual annotation), since this is a key preprocessing step.","section":"§3.2.4"},{"comment":"The failure case in Appendix A (Turn 15+16) is mentioned but not discussed in the main text. A brief analysis of why this segment fails would strengthen the paper's honest reporting of limitations.","section":"§4.2"},{"comment":"Reference [2] is given as 'Dust3r: Dual-scale transformer for sparse-to-dense matching' but the first author name is 'Qianqian Chen' and the title appears incomplete; verify all citations against the original publications. Also, reference [5] says 'to appear'—update if a final venue exists.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"This manuscript is closer to a project report than a full research article. The central feasibility claim is plausible and the authors are appropriately cautious, but the missing alignment specification and lack of any quantitative metric are substantive gaps that need to be filled before the paper can be considered for a serious venue. If the authors add a clear alignment procedure, numerical errors, and at least a small sensitivity analysis, the paper could become a useful empirical contribution. The current version is not publishable in its present form."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is an honest, clearly-scoped feasibility study. The paper doesn't claim a new reconstruction model; it shows what existing methods do on F1 onboard footage with hand-tuned preprocessing. The useful bits are real: bottom-half masking to remove the stationary car, chunking at straights so turns stay intact, and downsampling to 512x144 at 24 FPS. Those choices are described well enough to re-implement, the code is linked, and the negative results on AnyCAM are a legitimate reproducibility data point. I give the authors credit for stating plainly that the loop-closure step is unfinished and that the full track does not loop back.\n\nThe soft spots are the ones the reader and stress-test flagged, and I think the stress-test is right. The main positive claim—that each segment's reconstruction is \"very close to the ground truth map\" (Fig. 10)—rests on an overlay with no documented alignment procedure. MonST3R outputs pointmaps in an arbitrary scale and frame, so comparing them to the official track map requires estimating a similarity transform. If that transform was fit to maximize visual overlap, then the closeness is partly manufactured. The paper never states the alignment or reports any distance error. That makes the central evidence non-reproducible, and it's load-bearing because the whole feasibility argument depends on it.\n\nThe other issues are secondary but real: there are no numerical metrics anywhere (no ATE, RPE, or point-cloud error), and the preprocessing hyperparameters were tuned on the same video used for the final figures, so overfitting to this one sequence is plausible. These don't sink the paper because the authors are careful to say the reconstruction is partial and that there is significant work left. The conclusion sentence about \"scalable 4D reconstruction in real-world settings\" is a stretch, though, given the single track, single race, and qualitative evidence.\n\nWho gets value from this? People applying MonST3R or similar models to dynamic, high-speed camera footage, especially for sports broadcast or simulator-type use cases. The paper is a decent practical data point, not a scientific result with measured accuracy. I'd want to see a revised version with a stated alignment procedure, per-chunk distance errors, and ideally a second track or held-out sequence before treating the feasibility claim as established. For a workshop or short-paper venue, it deserves referee time; for a top conference, the missing evaluation would be a desk-reject-level gap. My recommendation: send it to review only after the authors add quantitative evaluation and specify the alignment.","headline":"Honest feasibility study: the preprocessing recipe is the real contribution, but the central 'close to ground truth' claim is unquantified and relies on an unspecified alignment step.","tokens_in":6448,"tokens_out":2205,"would_cite":false,"duration_ms":28255,"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":"Cropped, chunked onboard F1 video can partly rebuild a race track in 3D","keywords":["3D reconstruction","SLAM","MonST3R","Formula 1","onboard video","feed-forward depth","video preprocessing","Monaco Grand Prix"],"falsifier":"Take the predicted point cloud for turns 3, 4, and 5, align it to the official Monaco track map using a clearly stated method (e.g., rigid ICP seeded from the track's start line), and report the mean and 95th-percentile distance in meters. If the distances are much larger than the track width, the local-reconstruction claim fails. Alternatively, run the identical pipeline on a circuit with a known second lap and measure whether the loop-closure error is reproducible and grows with path length.","tokens_in":5544,"feed_emoji":"🏎️","tokens_out":2767,"duration_ms":35050,"temperature":0.7,"pith_summary":"The paper claims that a standard feed-forward 4D reconstruction model (MonST3R), when given onboard Formula 1 footage that has been downsampled, masked to hide the stationary car body, and split into five-second chunks at straight sections, can recover the local geometry of a race circuit and the car's trajectory. On the 2023 Monaco Grand Prix footage, each processed segment is reported to closely match the ground-truth track map, while stitching the chunks together drifts too far for the full lap to close the loop. The point is to show that heavy optimization-based SLAM is not the only route: existing learned reconstruction plus careful preprocessing can partially reconstruct a real, high-speed, dynamic outdoor scene. A sympathetic reading is that this demonstrates the feasibility of onboard-video 4D reconstruction, with global consistency left as the unsolved part.","feed_headline":"Cropped, chunked F1 video partly rebuilds Monaco in 3D","feed_subtitle":"A feed-forward model plus masking and straight-aware chunking recovers local track geometry, but the full lap won't loop shut.","key_machinery":"MonST3R, a feed-forward model that predicts per-frame 3D pointmaps in a common coordinate system from video, is the reconstruction engine. The paper adapts it with three preprocessing choices: masking out the bottom half of the frame to remove the stationary car body, downsampling to 512x144 at 24 FPS to fit memory and compute, and chunking video into overlapping five-second pieces split at straights so turns are not cut across chunks. Chunk-level reconstructions are stitched by transforming extrinsics through the one-frame overlap between chunks.","core_discovery":"The paper claims that the VROOM pipeline — MonST3R applied to bottom-half-masked, downsampled (512x144 at 24 FPS) onboard video, processed in five-second chunks split at straight sections — partially recovers track geometry and vehicle trajectories for the 2023 Monaco Grand Prix. Each individual chunk's reconstruction is stated to be very close to the ground-truth map (e.g., turns 3, 4, and 5), but the stitched full track does not loop back around, indicating accumulated drift across chunks. The paper also reports that AnyCam failed to recover plausible trajectories even on clean driving sequences, and that DROID-SLAM was abandoned due to visualization and static-scene limitations.","pith_inferences":["The claim that segments are 'very close to ground truth' depends on an unspecified alignment step; if the comparison involves fitting scale, rotation, and translation to maximize overlap, the reported closeness is partly a property of the fit, not the raw reconstruction. A distance error in meters after an explicitly stated alignment would settle this.","The one-frame overlap stitching is likely too weak a constraint to prevent drift over a 2-mile circuit; a pose-graph formulation with loop closure or global bundle adjustment is the natural extension the paper sketches.","The pipeline's success on Monaco, where walls are close to the car, may not transfer to tracks with open runoff areas and fewer nearby textures; testing on a different circuit would map the method's generality.","If multiple onboard cameras were fused, the paper's own reasoning implies the masking could be dropped entirely, since other views would disambiguate the car from static scene geometry — a testable multi-camera extension."],"forward_implications":["If per-chunk reconstructions are truly close to ground truth, then onboard race footage is a viable input for local 3D track mapping without custom SLAM systems.","The masking of the static car body is a cheap, effective fix that could transfer to any ego-vehicle reconstruction setting where the vehicle is visible in the frame.","Splitting video at straights rather than fixed intervals preserves the context needed to reconstruct curved sections, a preprocessing heuristic that could generalize to other racing or driving data.","The failure to close the loop defines the concrete next problem: global bundle adjustment across chunks or keyframe-based alignment is required before the method can produce a full-circuit map."],"supporting_citations":[{"why":"MonST3R is the feed-forward reconstruction model the pipeline is built on; it supplies the per-frame pointmap and camera motion estimates.","marker":"[10]"},{"why":"DUSt3R is the static-scene architecture that MonST3R adapts to dynamic settings, so the method's lineage rests on it.","marker":"[2]"},{"why":"DROID-SLAM is the optimization-based baseline the paper tried first and abandoned, serving as the comparison point for the learned feed-forward approach.","marker":"[9]"},{"why":"MegaSaM represents the dynamic-scene SLAM alternative in the related work, providing context for why a feed-forward method was chosen.","marker":"[5]"}],"fun_headline_variants":["F1 onboard video yields partial Monaco 3D reconstruction","Chunked F1 footage rebuilds Monaco track, but drift persists","Monaco 3D from racecam: pieces fit, lap doesn't close","VROOM: partial track rebuild from onboard F1 video","F1 cam video reconstructs Monaco, but lap drift remains"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The central evidence — that each chunk's reconstruction is 'very close' to the ground-truth map — rests on an unstated alignment procedure and visual comparison, with no quantitative distance error reported.","fun_headline_variants_meta":{"raw":{"variants":["F1 onboard video yields partial Monaco 3D reconstruction","Chunked F1 footage rebuilds Monaco track, but drift persists","Monaco 3D from racecam: pieces fit, lap doesn't close","VROOM: partial track rebuild from onboard F1 video","F1 cam video reconstructs Monaco, but lap drift remains"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000163,"raw_usage":{"total_tokens":1057,"prompt_tokens":698,"completion_tokens":359,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":442,"completion_tokens_details":{"reasoning_tokens":282}},"tokens_in":442,"tokens_out":359,"duration_ms":4507,"temperature":1.0,"reasoning_tokens":282,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T16:59:28.517735+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take the predicted point cloud for turns 3, 4, and 5, align it to the official Monaco track map using a clearly stated method (e.g., rigid ICP seeded from the track's start line), and report the mean and 95th-percentile distance in meters. If the distances are much larger than the track width, the local-reconstruction claim fails. Alternatively, run the identical pipeline on a circuit with a known second lap and measure whether the loop-closure error is reproducible and grows with path length.","supporting_citations":[{"cited_title":"Droid-slam: Deep visual slam for monocular, stereo, and rgb-d cameras","cited_arxiv_id":null,"evidence_quote":"MonST3R is the feed-forward reconstruction model the pipeline is built on; it supplies the per-frame pointmap and camera motion estimates."},{"cited_title":"Orb-slam3: An accurate open-source library for visual, visual–inertial, and multimap slam","cited_arxiv_id":null,"evidence_quote":"DUSt3R is the static-scene architecture that MonST3R adapts to dynamic settings, so the method's lineage rests on it."},{"cited_title":"Raft: Recurrent all-pairs field transforms for optical flow","cited_arxiv_id":null,"evidence_quote":"DROID-SLAM is the optimization-based baseline the paper tried first and abandoned, serving as the comparison point for the learned feed-forward approach."},{"cited_title":"Posenet: A convolutional network for real-time 6-dof camera relocalization","cited_arxiv_id":null,"evidence_quote":"MegaSaM represents the dynamic-scene SLAM alternative in the related work, providing context for why a feed-forward method was chosen."}],"review_version":1}