{"id":"7dd77560-e3a6-4fdd-a957-b5974f70330b","arxiv_id":"2509.06582","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A hybrid VR co-location framework uses headset SLAM tracking for low-latency motion and occasional motion capture realignment to keep multiple users aligned in a shared virtual space, with measured tracking errors around 3-5 cm.","lead":"This paper describes a VR system that lets several people share one physical room and appear in the same virtual room, by letting each headset do its own fast tracking and using a motion capture system only to re-align them when needed. It reports the virtual cameras stay within about 5 cm of the motion capture reference during multi-user tests.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Reported ATE may measure the documented 70 ms MoCap-HMD latency instead of spatial alignment: no timestamp synchronization is described before error computation.","rationale":"The reader centered on fixed calibration offset sensitivity, which is plausible, but the paper's own measurements raise a more immediate threat to internal validity. The authors measured a 70 ms MoCap/HMD latency and state it affects accuracy, yet never report time-aligning the data before computing ATE. That omission makes the headline numbers hard to interpret. The second issue—that the single-user evaluation deliberately avoids realignment—means the unique contribution (occasional dynamic correction) is not actually validated by the reported single-user experiments; multi-user trials may include corrections but this is not specified. Both concerns are checkable from the publicly available code/data. They do not necessarily invalidate the framework, but they make the central quantitative claim conditional on a re-analysis with synchronized timestamps and on an evaluation that logs correction events. Hence the verdict should remain conditional, with the added specific condition that ATE must be computed after temporal alignment and that the dynamic correction path must be exercised and reported.","tokens_in":11129,"tokens_out":4823,"duration_ms":45134,"concrete_test":"Recompute the ATE from the logged trajectories after shifting the MoCap reference by the measured 7-frame latency (or, better, using hardware timestamp synchronization); if the RMSE drops below roughly 1–2 cm, the published accuracy numbers are dominated by the temporal offset rather than by spatial co-location error. This single check separates the two error sources and settles whether the central claim is supported.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The load-bearing evidence is the ATE RMSE of 3.1–4.9 cm single-user and ~5.2 cm multi-user. Section 5.1 documents a constant 7-frame (70 ms at 100 Hz) offset between MoCap and HMD trajectories, but the paper never states that trajectories are time-aligned before ATE is computed. If they are not, each sample's error contains a temporal term of roughly v·0.07 s; at walking speeds around 1–1.4 m/s this alone yields 7–10 cm, comparable to or larger than the reported values. The published numbers could therefore quantify synchronization error, not the spatial co-location accuracy that the central claim asserts. Additionally, Section 4.1 states the single-user runs were performed 'without restarting or realigning the system' to observe drift, so the dynamic realignment component—the feature distinguishing this approach from one-time calibration—appears not to be exercised or measured; the ATE then characterizes one-time alignment plus SLAM drift, not hybrid correction. Section 6's mention of 'imperfect calibration offsets' does not address this temporal confounding.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a hybrid co-located VR tracking framework that uses each HMD's SLAM-based inside-out tracking as the primary pose source, with a motion capture system providing occasional realignment. The method first estimates a fixed SE(3) offset between the MoCap rigid body and the HMD's eye center, then computes the XR Origin transform so that the virtual camera coincides with the MoCap-derived eye pose; drift is monitored and corrected when a residual threshold is exceeded. Evaluation reports ATE RMSE of 3.1–4.9 cm for single-user motions and about 5.2 cm for each user in a two-user fist-bump scenario, plus a measured 70 ms MoCap-to-HMD latency.","tokens_in":11374,"tokens_out":4828,"duration_ms":41909,"significance":"If the reported accuracy is trustworthy, the framework is a useful practical contribution: it offers a simple, open-source path to co-located VR with commercial HMDs, and the mathematical formulation is clean and correct. The paper's strengths include a clear SE(3) derivation, a yaw-only alignment reduction to preserve floor leveling, and a publicly available GitHub release. However, the evaluation as reported does not yet substantiate the central hybrid-realignment claim: the ATE numbers may be contaminated by the documented 70 ms latency, the single-user protocol deliberately avoids realignment, and no inter-user relative error is reported. The core idea is defensible, but the evidence needs strengthening before the accuracy and comfort claims are supported.","major_comments":[{"comment":"The ATE computation is not described as including temporal synchronization between the MoCap and HMD trajectories. Section 5.1 reports a constant 7-frame (70 ms) offset between these signals. If this offset is not removed before computing the RMSE, each sample's error contains a temporal term of roughly v·0.07 s; at walking speeds of 1–1.4 m/s this alone contributes 7–10 cm, which is comparable to or larger than the reported 3.1–4.9 cm. Please state explicitly whether the trajectories were time-aligned before computing the values in Table 1, and if they were not, re-run the evaluation with temporal alignment.","section":"§5.2, Table 1; §5.1"},{"comment":"The single-user trials were executed 'without restarting or realigning the system' to observe cumulative drift, which means the dynamic alignment correction described in Section 3.6 was deliberately not exercised during the accuracy evaluation. The reported ATE therefore measures the accuracy of the one-time calibration plus accumulated SLAM drift, not the hybrid correction loop that distinguishes this system from prior work. The paper provides no data on correction frequency, threshold sensitivity, or accuracy immediately after a realignment event; this evidence is needed to support the central hybrid-system claim.","section":"§4.1 and §5.2"},{"comment":"Co-location accuracy is fundamentally an inter-user relative quantity, but the multi-user ATE is reported as per-user absolute error against the MoCap reference. This metric does not directly quantify the error in the relative pose between users, which is what determines whether a fist bump or other close interaction is spatially correct. In addition, the values in Table 2 are averages over only three runs with no reported spread or confidence interval. Please report an inter-user relative error metric (for example, the difference between the MoCap-derived and HMD-derived relative position of the two users) and provide per-run values or standard deviations.","section":"§5.3, Table 2"},{"comment":"The extrinsic calibration offset T_EyeLocal_Mocap is estimated from MoCap and HMD trajectories, and Section 6 attributes residual error to 'imperfect calibration offsets' without quantifying the sensitivity of the final alignment to this parameter. Because the same calibration is used in the ATE evaluation, the reported accuracy is conditional on the offset remaining rigidly fixed and unbiased. Please report the calibration residual, assess its temporal stability, and, if possible, evaluate the ATE with a held-out session or a calibration trajectory different from the evaluation trajectories.","section":"§3.2.2 and §6"}],"minor_comments":[{"comment":"There are typographical errors in the manuscript: 'abreviate' should be 'abbreviate' in Section 3.3, and the heading 'Singe-user Evaluation' in Section 4.1 should be 'Single-user Evaluation'.","section":"§3.3 and §4.1"},{"comment":"The right-handed to left-handed coordinate-system conversion is mentioned but not specified; a brief description of the axis mapping would help readers reproduce the framework.","section":"§3.4"},{"comment":"The text states that the limitations of frame-based latency estimation 'are negligible in this setup' but does not provide evidence for this claim; a short justification based on the stable logging rate or the cross-correlation peak sharpness would strengthen the latency discussion.","section":"§5.1"},{"comment":"The conclusion that the approach 'completely mitigates the latency introduced by continuous pose streaming' is too strong given that external tracking is still used for calibration and occasional correction; consider a more measured phrasing such as 'largely avoids the sustained latency of continuous streaming'.","section":"§7"}],"recommendation":"major_revision","confidential_remarks":"The manuscript fits the workshop scope and the underlying concept is reasonable. The main issue is internal validity of the evaluation rather than the derivation. The temporal-alignment question is the most serious: if the ATE was computed without time synchronization, the headline numbers may reflect the 70 ms latency rather than spatial alignment. I believe the authors can address this by re-analyzing their logged data, so I am not recommending rejection, but the revision needs to be substantive."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should read this paper if you work on co-located VR or multi-user tracking. The core idea is simple and sound: run inside-out SLAM on each HMD most of the time, and only invoke motion-capture realignment when drift exceeds a threshold. That is a real step beyond continuous MoCap (Holojam, Braun et al.) and one-time calibration (McGill et al., Reimer et al.). The SE(3) derivation that computes the XR Origin transform is correct and clearly explained, and the system is modular with public code. I also give them credit for measuring the MoCap-HMD latency via cross-correlation and reporting it; that is exactly the kind of number a systems paper should include.\n\nThe soft spots are in the evaluation, and one of them is serious. Section 5.1 reports a constant 7-frame (70 ms) offset between MoCap and HMD trajectories, but the paper never states that the trajectories are time-aligned before ATE is computed. If they are not, each ATE sample contains a temporal term around v·0.07 s; at walking speeds of 1–1.4 m/s that is 7–10 cm, which is comparable to or larger than the reported 3–5 cm errors. So the headline numbers may be measuring synchronization error rather than spatial alignment. This is not fatal because the authors clearly know about the latency, but it is an omission that a referee must force them to fix.\n\nThe second gap is structural: the single-user evaluation was performed \"without restarting or realigning the system\" to observe drift. That means the dynamic realignment component—the one thing that distinguishes this paper from one-time calibration—is never actually exercised or measured. The multi-user runs may have triggered corrections, but the paper does not say, so we have no evidence that the hybrid loop improves accuracy. A simple baseline test with and without realignment, or at least a log of when corrections fired, would close this hole.\n\nMinor issues: no error bars, no same-environment comparison against continuous MoCap, no direct inter-user relative error metric (the fist-bump successes are a decent qualitative probe, but not a number). The calibration offset sensitivity is mentioned but not quantified; Section 6 attributes errors to \"imperfect calibration offsets\" without showing how much a small slip matters.\n\nOverall: the architecture is worth building on, the writing is clear, and the math holds up. The evaluation is under-powered and at least one number is probably contaminated, but this is a solid workshop-to-conference systems contribution after a serious revision. I would send it to a competent reviewer and ask for: (1) explicit time alignment in ATE, or a report of both raw and latency-compensated errors; (2) a test that actually triggers dynamic realignment; (3) error bars and a baseline. Not desk-reject material.","headline":"A genuinely useful hybrid tracking architecture for co-located VR, but the ATE evaluation is likely confounded by the documented 70 ms MoCap latency and never exercises the dynamic realignment loop that defines the contribution.","tokens_in":11878,"tokens_out":2772,"would_cite":false,"duration_ms":26176,"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":"Hybrid tracking makes co-located VR accurate by using headset SLAM every frame and motion capture only to fix drift.","keywords":["co-located VR","hybrid tracking","motion capture","SLAM","inside-out tracking","multi-user virtual reality","dynamic alignment correction","head-mounted display"],"falsifier":"Deliberately loosen or shift the marker-carrying rigid body on the headset by a few millimeters mid-session and watch the ATE: if the residuals move correspondingly, the fixed-offset assumption is load-bearing. Independently, run the extrinsics calibration twice and compute the ATE difference under each offset estimate; a large swing would show that the reported 3–5 cm accuracy is conditional on a single calibration.","tokens_in":10957,"feed_emoji":"🥽","tokens_out":5911,"duration_ms":51346,"temperature":0.7,"pith_summary":"This paper proposes a middle path for multi-user VR co-location: let each headset's inside-out SLAM tracking run continuously for low-latency pose updates, and use an external motion-capture system only to detect drift and occasionally realign users to a shared physical frame. The authors argue that this hybrid avoids the two failure modes of existing approaches—one-time calibration cannot correct drift, while continuous external tracking injects latency and jitter that cause cybersickness. They report single-user absolute trajectory errors of roughly 3.1 to 4.9 centimeters root-mean-square, multi-user errors near 5.2 centimeters per user, and successful fist-bump interactions in all trials. If the claim holds, co-located VR can keep the responsiveness of standalone headsets while preserving centimeter-level inter-user alignment, with external infrastructure used sparingly rather than continuously.","feed_headline":"VR co-location hits ~5 cm accuracy without MoCap latency","feed_subtitle":"Headset SLAM runs every frame; motion capture steps in only when drift appears, keeping users aligned.","key_machinery":"The load-bearing object is the fixed rigid transform $T_{\\mathrm{EyeLocal}}^{\\mathrm{Mocap}} \\in \\mathrm{SE}(3)$ from the motion-capture rigid body to the HMD's eye-center frame, estimated once by least-squares alignment of synchronized trajectories. The alignment step solves $T_{\\mathrm{XROW}} = T_{\\mathrm{EyeW}} \\cdot (T_{\\mathrm{CamL}})^{-1}$ to place the XR Origin so that the virtual camera matches the MoCap-derived eye pose, and the dynamic alignment correction re-applies this solve whenever the residual between SLAM-derived and MoCap-derived poses exceeds a threshold. A yaw-only variant of the solve prevents the tracking space from inheriting a tilt from the user's head orientation during alignment. This loop is what lets the system run at the HMD's native frame rate while still correcting drift or tracking loss.","core_discovery":"The paper's central claim is that a hybrid loop—HMD SLAM supplying every-frame pose estimates, with motion capture reserved for drift-triggered realignment—achieves the accuracy needed for co-located multi-user VR without inheriting the latency of continuous external tracking. The system first estimates a constant rigid offset $T_{\\mathrm{EyeLocal}}^{\\mathrm{Mocap}} \\in \\mathrm{SE}(3)$ between the MoCap marker frame and the HMD's eye-center frame, then sets the XR Origin transform so the virtual camera coincides with the MoCap-derived eye pose. During operation, the residual between the HMD SLAM pose and the MoCap pose is monitored, and only when it exceeds a configurable threshold is a realignment applied. In the reported experiments, single-user ATE RMSE values are 3.102–4.880 cm, multi-user values are 5.192 and 5.184 cm, the measured MoCap-to-HMD latency is about 70 ms, and all fist-bump trials succeeded. The authors present these numbers as evidence that sparse realignment preserves spatial consistency while keeping the responsiveness of native headset tracking.","pith_inferences":["We infer that the reported 70 ms latency is a floor for this setup: under network congestion the cross-correlation shift could grow, and the threshold-triggered design would then either correct less often or align to stale MoCap poses, an interaction the paper does not model.","If the fixed-offset assumption is the limiting factor, a natural extension would be continuous online refinement of $T_{\\mathrm{EyeLocal}}^{\\mathrm{Mocap}}$ whenever the residual is small, turning an offline calibration into a self-maintaining estimate.","The same sparse-alignment pattern could be driven by collaborative SLAM map sharing instead of motion capture, with external tracking used only to bootstrap the first shared frame; this would reduce dependence on external infrastructure while retaining the paper's correction mechanism."],"forward_implications":["Because the HMD's SLAM pose is used every frame, the roughly 70 ms MoCap latency is kept out of the per-frame tracking path, so the user-facing responsiveness is that of the headset rather than the external system.","Drift or temporary SLAM failure no longer requires restarting the session; a realignment event pulls the user back to the shared physical frame.","The reported accuracy, with ATE RMSE of 3–5 cm and successful fist-bump interactions, supports close-proximity collaborative tasks such as hand-to-hand contact in co-located VR.","The residual threshold is exposed as a configurable parameter, allowing operators to trade alignment strictness against how often corrections are triggered.","The modular design around a standard XR interface and a generic MoCap stream means the same method can pair different SLAM-tracking headsets with different external tracking systems."],"supporting_citations":[{"why":"Defines the co-located mixed-reality alignment problem and the one-time manual alignment baselines this approach must outperform.","marker":"[5]"},{"why":"Supplies the comparison point for tracking errors in state-of-the-art XR headsets, including the roughly 12 cm difficult-scenario error this work cites.","marker":"[11]"},{"why":"Describes a prior SLAM-tracked HMD co-location method using marker-based alignment, which the hybrid approach extends with dynamic corrections.","marker":"[6]"},{"why":"Documents a continuous MoCap-based co-located system whose network latency led to cybersickness, motivating the sparse-realignment design.","marker":"[4]"},{"why":"Provides the least-squares similarity transformation used to estimate the eye-center offset between MoCap and HMD frames.","marker":"[34]"},{"why":"Supplies the networking infrastructure for transmitting user pose data between client instances for multi-user pose sharing.","marker":"[38]"}],"fun_headline_variants":["Sparse MoCap realigns VR only when drift appears","Hybrid VR tracking: SLAM each frame, MoCap on demand","VR co-location: 5 cm accuracy, MoCap only on drift","MoCap only when drift: VR co-location stays smooth","HMD SLAM plus occasional MoCap achieves VR co-location"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"Everything rests on the once-per-session rigid offset between the motion-capture marker frame and the headset's eye-center frame staying exactly fixed; if the marker-carrying rigid body slips, or the least-squares estimate is biased by the 70 ms latency between MoCap and HMD signals, every subsequent alignment and every ATE measurement inherits that error.","fun_headline_variants_meta":{"raw":{"variants":["Sparse MoCap realigns VR only when drift appears","Hybrid VR tracking: SLAM each frame, MoCap on demand","VR co-location: 5 cm accuracy, MoCap only on drift","MoCap only when drift: VR co-location stays smooth","HMD SLAM plus occasional MoCap achieves VR co-location"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000929,"raw_usage":{"total_tokens":3965,"prompt_tokens":917,"completion_tokens":3048,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":533,"completion_tokens_details":{"reasoning_tokens":2956}},"tokens_in":533,"tokens_out":3048,"duration_ms":17752,"temperature":1.0,"reasoning_tokens":2956,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T16:15:23.919732+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deliberately loosen or shift the marker-carrying rigid body on the headset by a few millimeters mid-session and watch the ATE: if the residuals move correspondingly, the fixed-offset assumption is load-bearing. Independently, run the extrinsics calibration twice and compute the ATE difference under each offset estimate; a large swing would show that the reported 3–5 cm accuracy is conditional on a single calibration.","supporting_citations":[{"cited_title":"A quest for co-located mixed reality: Aligning and assessing slam tracking for same-space multi-user experiences,","cited_arxiv_id":null,"evidence_quote":"Defines the co-located mixed-reality alignment problem and the one-time manual alignment baselines this approach must outperform."},{"cited_title":"Apple vs. meta: A com- parative study on spatial tracking in sota xr headsets,","cited_arxiv_id":null,"evidence_quote":"Supplies the comparison point for tracking errors in state-of-the-art XR headsets, including the roughly 12 cm difficult-scenario error this work cites."},{"cited_title":"Colocation for slam-tracked vr headsets with hand tracking,","cited_arxiv_id":null,"evidence_quote":"Describes a prior SLAM-tracked HMD co-location method using marker-based alignment, which the hybrid approach extends with dynamic corrections."},{"cited_title":"Co-located augmented and virtual reality systems,","cited_arxiv_id":null,"evidence_quote":"Documents a continuous MoCap-based co-located system whose network latency led to cybersickness, motivating the sparse-realignment design."},{"cited_title":"Colibri: A toolkit for rapid prototyping of networking across realities,","cited_arxiv_id":null,"evidence_quote":"Supplies the networking infrastructure for transmitting user pose data between client instances for multi-user pose sharing."}],"review_version":2}