{"id":"07cc3033-b4ae-4c1f-84de-c90020683930","arxiv_id":"1908.03118","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"A set of three filtering optimizations to a volumetric reconstruction and streaming pipeline raises the number of simultaneous remote viewers in most test scenes from single digits to more than 24.","lead":"This paper improves a live 3D telepresence system so that larger groups can view the same reconstructed scene at the same time. It reports supporting more than 24 remote viewers in most test scenes, up from roughly 3 to 5 with the original system.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The >24-client scalability claim is measured with discard-only benchmark clients that omit the rendering pipeline, so the headline has not been demonstrated for real immersive clients.","rationale":"The paper's contribution is a set of three filtering/pruning optimizations on top of SLAMCast, and the ablation study is informative; the engineering direction is plausible. The load-bearing condition for the central claim is that the benchmark client faithfully represents an immersive exploration client. That condition is not met as reported: the benchmark intentionally discards all received data and is colocated with all other benchmark clients, so client-side mesh integration, rendering, and per-client back-pressure are absent. This is the same weakness the reader identified, and it is compounded by the copyroom row of Table 1 contradicting the unqualified 'more than 24' claim. Both concerns are addressable with a real-client test and do not falsify the proposed approach. I therefore agree with the reader's CONDITIONAL verdict and would keep it unchanged.","tokens_in":11433,"tokens_out":4953,"duration_ms":59139,"concrete_test":"Run the Ours configuration with N = 24 actual exploration clients (the full mesh-generating, rendering client from SLAMCast, not the discard benchmark), each on a separate machine with the same GTX 1080 hardware, connected over the same local network, on the copyroom and heating room sequences. Record per-client end-to-end latency and the maximum number of clients that can be served before the delay exceeds the single-client baseline by one second, the paper's own criterion. If N >= 24 holds for heating room but copyroom reaches only 18, revise the headline to per-dataset maximum client counts.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central scalability number—more than 24 simultaneous exploration clients (Abstract, Section 6.1, Table 1)—is measured with a benchmark client that 'discards the received data', with all benchmark clients running on a single computer (Section 6.1). This removes the client-side work the system is meant to preserve: receiving MC voxel blocks, maintaining a local mesh, and rendering the VR view. It also removes realistic request timing, since a discarding client can issue fixed 12 Hz requests without back-pressure from rendering, mesh integration, or network processing of a displayed model. The server-side per-client state and streaming cost are still exercised, but end-to-end latency and maximum client count are measured without the display pipeline. Section 6.1 explicitly says the discard choice is 'without an overhead', so the claim 'more than 24 users ... without introducing further latency' is only validated for non-rendering clients. In addition, the paper's own Table 1 lists only 18 ECs for copyroom under Ours, while the Abstract and Conclusion claim more than 24 clients without qualification; the scope of the claim needs to be stated per dataset. These issues are empirical and fixable, so they do not undermine the engineering direction, but they do prevent the headline from being accepted as stated.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes three optimizations to a SLAMCast-style volumetric telepresence pipeline: filtering depth discontinuities, virtual downsampling of voxel block allocation, and pruning of empty or unstable Marching Cubes voxel blocks on the server. Combined, these are claimed to allow more than 24 concurrent exploration clients in the same live-captured scene, about a factor of 6 more than the prior SLAMCast system, without additional latency or hardware changes. The claims are evaluated on five datasets using benchmark clients that discard received data.","tokens_in":11672,"tokens_out":4763,"duration_ms":45555,"significance":"The engineering direction is valuable: the proposed filters are simple, described concretely, and the ablation (B, B+DDF, B+VBAD, B+MCVBP, Ours) shows a clear stepwise reduction in model size, bandwidth, and latency. If the scalability claim were validated with realistic clients, the system would be a practical contribution to group-scale VR telepresence on consumer hardware. The paper also demonstrates the benefit of the filters for standalone volumetric reconstruction. However, the evaluation methodology currently prevents the headline result from being accepted as stated.","major_comments":[{"comment":"The Abstract, Section 6.1, and Conclusion claim that the system supports 'more than 24 clients in all scenes', but Table 1 reports a maximum of 18 exploration clients for the copyroom dataset under Ours. The unqualified claim is therefore not supported by the data; the authors should either qualify the claim per dataset or explain why copyroom is exceptional.","section":"Abstract, Section 6.1, Table 1"},{"comment":"The scalability and latency results are obtained with benchmark clients that discard all received data and run on the same computer as the other benchmark clients. This removes client-side mesh integration, rendering, and display, as well as the realistic request timing induced by rendering load. Consequently, the measured maximum of more than 24 clients and the claim of 'without introducing further latency' apply only to non-rendering clients, not to the immersive VR clients the system is designed for. The authors should either measure with at least one realistic rendering client or provide evidence that the discard benchmark is a faithful proxy (e.g., compare request timing and client-side resource usage).","section":"Section 6.1, Evaluation setup"},{"comment":"The filter thresholds (cd, ch, ca, cw) are 'determined empirically using several datasets' (Section 6), and the same datasets are used for the reported evaluation. Without a held-out validation set or a sensitivity analysis, the reported improvements may be optimistic and the transferability of the chosen thresholds is unclear. Please include a sensitivity analysis or validation on at least one held-out sequence.","section":"Section 6, Filter tuning"}],"minor_comments":[{"comment":"The sentence 'which allows for running all benchmark clients on a single computer without an overhead' is vague; please specify what overhead is avoided (e.g., no rendering, no mesh integration, no display costs).","section":"Section 6.1"},{"comment":"The notation 'M MC/P MC A (M T SDF)' is not explained; please add a sentence clarifying that the two numbers under Model Size correspond to the MC model size and the update-set size, with the TSDF size in parentheses.","section":"Table 1 caption"},{"comment":"The label 'S MC US' is used but not defined; please define it as the update set size P_MC_A to avoid confusion.","section":"Section 6.2, Figures 4 and 5"},{"comment":"The set-builder condition mixes an existential quantifier over neighbors with a condition on the whole neighborhood; please clarify the logical precedence or split the condition into two explicit clauses.","section":"Section 4.1, Eq. (1)"},{"comment":"The reported improvements of '10-40%' for runtime and '25-60%' for memory would be more useful if accompanied by a per-dataset table with exact values.","section":"Section 6.3"}],"recommendation":"major_revision","confidential_remarks":"The paper is a straightforward engineering contribution with clear descriptions and a useful ablation. The main risk is overclaiming 'more than 24 clients' given the copyroom result and the discard-only benchmark. The authors should be able to address these concerns with additional experiments or a more careful scope statement; I do not see a fundamental flaw that would require rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things about this paper. It's a genuinely useful systems paper: three simple filters added to the SLAMCast pipeline—depth discontinuity rejection, virtual downsampling of voxel block allocation, and pruning of empty or unstable Marching Cubes blocks—lift the measured client ceiling from single digits to 18-28 across five scenes, with a clean ablation showing each filter's contribution. But the paper's own abstract and Section 6.1 claim 'more than 24 clients in all scenes,' while Table 1 reports 18 for the copyroom dataset. The headline is false for that dataset, and the conclusion repeats the overclaim.\n\nThe novelty is modest, and the authors say so: they are optimizing an existing system, not inventing new reconstruction or streaming methods. That's fine; the contribution is in the combination and the careful evaluation. Each filter is grounded in known ideas, and the measurements of latency, memory, and model size over time are concrete and mostly convincing. I trust the direction: the filters do reduce streaming load, and the factor of six improvement over their own baseline is plausible.\n\nThe soft spots are real but addressable. First, the scalability numbers come from a benchmark client that discards received data and runs all clients on one computer. This exercises the server's per-client state and streaming, but not the client-side rendering, mesh integration, request timing, or back-pressure that an immersive user would generate. So 'more than 24 users' is not actually demonstrated; the measured number is a server-capacity upper bound. That should be stated clearly, and ideally validated with a few real clients. Second, the threshold tuning isn't fully described; if the thresholds were chosen on the evaluation scenes, the generalization is uncertain. That's a minor point for an engineering paper, but worth noting. Third, no code or data are released, which limits reproducibility.\n\nThe main argument holds up. This is a paper for people building live telepresence or streaming voxel reconstruction systems; it gives them concrete, well-tested optimizations. If it came across my desk, I'd send it to reviewers. It needs a fix of the copyroom discrepancy and a more honest description of the scalability limit before it's accepted as stated, but it deserves a serious referee rather than a desk rejection.","headline":"A solid systems paper with a genuine scalability win, but the >24-client claim is factually wrong for one scene and the benchmark clients omit the rendering pipeline; worth a revised version, not as printed.","tokens_in":12175,"tokens_out":5522,"would_cite":true,"duration_ms":52383,"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":"By filtering unreliable depth data and pruning empty surface blocks, a live telepresence pipeline can stream one captured scene to more than 24 exploration clients at once.","keywords":["live telepresence","3D reconstruction","TSDF voxel blocks","voxel hashing","Marching Cubes pruning","depth discontinuity filtering","multi-client streaming","virtual reality"],"falsifier":"Run the described server with 24 actual exploration clients that render the received blocks in VR on separate computers over a realistic network, and count how many can keep their local model within the one-second sync delay used in the paper; if that number is below 24, the claimed capacity does not transfer to real immersive use.","tokens_in":11241,"feed_emoji":"🕶️","tokens_out":5838,"duration_ms":58532,"temperature":0.7,"pith_summary":"This paper argues that a live telepresence system built on voxel-block 3D reconstruction can serve a group of more than 24 remote exploration clients in the same live-captured scene, about six times more than the roughly 4 clients supported by the prior SLAMCast system, without added latency or new hardware. The route is not a new capture or transmission architecture but three filters that keep unreliable data out of the reconstruction and the stream: depth samples at discontinuities are discarded, voxel block allocation is virtually downsampled, and empty or unstable Marching Cubes blocks are pruned on the server. If true, group-scale immersive telepresence for education, entertainment, and collaboration becomes feasible on consumer hardware, and the same filters also improve standalone volumetric reconstruction.","feed_headline":"Depth filters lift live VR telepresence from 4 to 24 clients","feed_subtitle":"Three pruning tricks let more than two dozen people share one live-captured scene on consumer PCs.","key_machinery":"The load-bearing mechanism is a three-part filtering pipeline around a sparse voxel-block truncated signed distance field (TSDF) scene representation. A depth-discontinuity filter discards depth samples whose values deviate strongly from their 7x7 neighborhood or whose neighborhood has too many missing measurements; a virtual downsampling step during voxel block allocation considers only every $c_a$-th pixel so fewer empty blocks are created; and a Marching Cubes voxel block pruning step on the server drops blocks whose MC index is $0$ or $255$ or whose TSDF fusion weight falls below a threshold, so only reliable surface blocks enter the stream. Together these filters shrink the streaming model and the update set, which is what raises client capacity.","core_discovery":"The central claim is that filtering unreliable depth pixels before fusion, allocating voxel blocks from a virtually downsampled depth image, and pruning empty or low-weight Marching Cubes blocks in the server's streaming model collectively reduce the server's model size and the client request rate enough that the same pipeline that handled 3-5 clients can handle more than 24. In the evaluation, the full system lowered the required request rate to 12 Hz for most scenes and cut memory footprint by 25-60% compared with the base approach. The paper presents this as an optimization of an existing pipeline rather than a new reconstruction algorithm, and it demonstrates that each individual filter contributes a measurable gain in client count, latency, or visual quality.","pith_inferences":["If real rendering clients behave like the benchmark discard clients, the 24-client number is likely optimistic; actual immersive users add GPU load and different request timing, so field deployments should expect a lower ceiling until re-measured.","The pruning threshold and downsampling factor are fixed empirically in the paper; an adaptive policy that tunes $c_w$ and $c_a$ per scene or per depth range could preserve the scalability gains while recovering some of the holes that aggressive downsampling can cause at long range.","The same block-level pruning idea could be applied to collaborative multi-client reconstruction, where submap fusion would benefit from ignoring unstable blocks without deleting geometry that later revisits might stabilize.","A natural stress test is to combine this server-side pruning with a real VR client on a laptop-class GPU, measuring both network and render latency under the same 12 Hz request rate."],"forward_implications":["More than 24 users can explore the same live-captured scene at once on consumer hardware, supporting classroom, entertainment, and remote-collaboration settings.","The required client request rate drops to about 12 Hz for most tested scenes, so server bandwidth and per-request overhead are no longer the bottleneck they were at 100 Hz.","Reconstructed models become noticeably more compact, with reported memory reductions of 25-60%, while visual artifacts around depth discontinuities and poorly observed regions are reduced.","The same filters apply to standalone volumetric reconstruction, not just telepresence, improving runtime and memory there too.","Because latency between server and client stays low across the capture sequence, reconnecting clients can catch up quickly after network interruptions."],"supporting_citations":[{"why":"This is the baseline SLAMCast system that the paper optimizes, supplying both the pipeline and the roughly four-client comparison ceiling.","marker":"[27]"},{"why":"This work supplies the voxel-hashing allocation and the garbage-collection idea that the new pruning filters extend.","marker":"[23]"},{"why":"This work provides the depth-discontinuity filtering idea applied during image preprocessing.","marker":"[31]"},{"why":"This algorithm generates the Marching Cubes indices used to decide which blocks are empty or unstable.","marker":"[15]"},{"why":"This point-based fusion work inspires the decision to ignore low-weight, unstable voxels rather than delete them.","marker":"[14]"},{"why":"This work supplies the compact TSDF and weight encoding and the GPU-CPU streaming mechanism the server relies on.","marker":"[12]"}],"fun_headline_variants":["Depth filtering scales live VR telepresence to 24 clients","Sixfold client increase for live 3D telepresence via pruning","24 users, one scene: depth optimizations for VR streaming","Consumer PCs stream VR to 24 people with depth filters","Live telepresence handles 24 clients via depth-aware optimizations"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The measured client ceiling assumes that a benchmark client that discards every received block and runs on the same computer as all other benchmark clients behaves like a real exploration client that renders the scene on its own hardware.","fun_headline_variants_meta":{"raw":{"variants":["Depth filtering scales live VR telepresence to 24 clients","Sixfold client increase for live 3D telepresence via pruning","24 users, one scene: depth optimizations for VR streaming","Consumer PCs stream VR to 24 people with depth filters","Live telepresence handles 24 clients via depth-aware optimizations"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000668,"raw_usage":{"total_tokens":3013,"prompt_tokens":877,"completion_tokens":2136,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":493,"completion_tokens_details":{"reasoning_tokens":2048}},"tokens_in":493,"tokens_out":2136,"duration_ms":17074,"temperature":1.0,"reasoning_tokens":2048,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T14:24:13.439670+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the described server with 24 actual exploration clients that render the received blocks in VR on separate computers over a realistic network, and count how many can keep their local model within the one-second sync delay used in the paper; if that number is below 24, the claimed capacity does not transfer to real immersive use.","supporting_citations":[{"cited_title":"Stotko, S","cited_arxiv_id":null,"evidence_quote":"This is the baseline SLAMCast system that the paper optimizes, supplying both the pipeline and the roughly four-client comparison ceiling."},{"cited_title":"Nießner, M","cited_arxiv_id":null,"evidence_quote":"This work supplies the voxel-hashing allocation and the garbage-collection idea that the new pruning filters extend."},{"cited_title":"Whelan, M","cited_arxiv_id":null,"evidence_quote":"This work provides the depth-discontinuity filtering idea applied during image preprocessing."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"This algorithm generates the Marching Cubes indices used to decide which blocks are empty or unstable."},{"cited_title":"Keller, D","cited_arxiv_id":null,"evidence_quote":"This point-based fusion work inspires the decision to ignore low-weight, unstable voxels rather than delete them."},{"cited_title":"K¨ahler, V","cited_arxiv_id":null,"evidence_quote":"This work supplies the compact TSDF and weight encoding and the GPU-CPU streaming mechanism the server relies on."}],"review_version":1}