DeltaFlow: An Efficient Multi-frame Scene Flow Estimation Method

Thanks for the valuable comments! We have addressed your concerns and questions individually below.

W1: Decay Factor

We apologize if the explanation regarding the decay factor was not sufficiently clear and are happy to summarize our findings here.

As shown in Figure 4 and Table 6, our Δ scheme already outperforms prior state-of-the-art (Flow4D) even with no decay applied (λ = 1). While applying a decay factor (λ < 1) yields modest but consistent improvements, the method is not highly sensitive to the specific value chosen, highlighting the robustness of the approach.

For this initial study, we adopted a simple fixed decay for clarity. We agree that learning λ dynamically based on scene characteristics is a promising direction for future work and can build on this foundation.

W2: Comparison with Floxels

A comparison with Floxels is included in Table 1 (Page 7). As shown, ΔFlow achieves 26% lower dynamic bucket-normalized error (0.113 vs. 0.154), 42% lower three-way EPE, and is approximately 180× faster (8s vs. 24mins per sequence).

Given that Floxels is an offline optimization-based method rather than feed-forward, we focused our detailed comparisons on real-time supervised approaches such as Flow4D and DeFlow. We believe the Δ scheme could complement future multi-frame SSL pipelines like Floxels, and we see this as a promising direction for future work.

Thanks for the valuable comments! We have addressed your concerns and questions individually below.

W1: Ground Truth Annotation

We acknowledge that our current experiments use full supervision and note this as a limitation (Lines 298–302). However, the core ΔFlow framework is modular and adaptable to other objectives, such as self-supervised learning.

To demonstrate compatibility with self-supervised learning, we replace the fully supervised loss with the losses proposed in SeFlow. The training result is shown in Table R2, which confirms that ΔFlow can operate effectively without labeled data and even improve existing SSL accuracy. Specifically, this ΔFlow-SSL variant reduced mean bucket-normalized EPE from 0.3996→0.3346 (~16%) and 3-way EPE from 6.29→5.17 cm (~18%) compared with SeFlow, while running at 8s per sequence, orders of magnitude faster than optimization-based NSFP (~1h).

Table R2: Self-supervised methods, performance evaluated on Argoverse 2 validation set.

W2 & Q2: Single input still 15 frames

While our current experiments use a 15-frame window, this is not an architectural limit. As shown in Table 3, performance saturates empirically around 10 frames, and we found limited additional benefit beyond 15. Therefore, this design choice reflects a research finding, not a technical constraint.

Architecturally, ΔFlow is fully scalable. As detailed in Appendix D.1, our sparse Δ scheme implementation ensures that even at 15 frames, active Δ voxels occupy less than 1% of a dense grid. This enables the processing of longer sequences. Compared to prior work (e.g., Flow4D), ΔFlow handles longer temporal windows more efficiently.

Although our findings suggest diminishing returns beyond 15 frames, we note that this already represents one of the longest aggregation windows among current real-time methods. Given the 10 FPS rate of the datasets used, 15 frames span approximately 1.5 seconds, which is generally sufficient to capture relevant motion dynamics. For example, in scenarios where a vehicle transitions from steady movement to a sharp turn, earlier frames may contribute less to predicting current motion.

This observation is also consistent with prior work. For instance, Floxels reports optimal performance with 9–13 frames, and methods like Flow4D and MambaFlow are similarly evaluated on shorter windows.

Q1: More Video Performance

Due to NeurIPS rebuttal guidelines, we are unable to include figures at this stage. However, we have provided qualitative results in Fig. 5, Fig. 9, Fig. 10, and Fig. 11 to illustrate real-world performance. In the final version, we will include a public project page with additional inference videos to allow readers to further assess ΔFlow’s behavior across diverse scenarios.

Thanks for the valuable comments! We have addressed your concerns and questions individually below.

W1 & Q1 & L1: Sensitivity to Noise

LiDAR noise can be broadly categorized as either structured noise (e.g., consistent noise pattern across multiple frames) or unstructured noise (e.g., random sensor jitter).

For structured noise, our Δ scheme helps mitigate its impact, as consistent patterns across frames are reduced through the subtraction step, allowing the network to better focus on the underlying motion signals; For unstructured noise, our Δ scheme reinforces coherent motion signals. As a result, the signal-to-noise ratio remains stable. Accumulated motion signals tend to form distinct, directional trails, making them easier to distinguish from scattered noise, which the network learns to recognize during training.

Please note that a full noise ablation is beyond the current scope; all our experiments are conducted on real-world datasets (Argoverse 2, Waymo, and the newly added nuScenes), which naturally include sensor drift, dropouts, and occlusions, etc. ΔFlow achieves SOTA performance across these benchmarks, confirming its robustness in noisy environments.

Q2 & L2: Dataset Diversity

We selected Argoverse 2 and Waymo as primary benchmarks because they are currently the only public LiDAR datasets with official scene flow ground truth and leaderboards, enabling large-scale, fair evaluation. While both focus on urban traffic, they differ in sensor setups and scan patterns, providing a meaningful basis for cross-domain generalization.

In response to your suggestion for broader validation, we have additionally evaluated ΔFlow on nuScenes (Table R1), which features a single 32-beam LiDAR and includes diverse lighting and weather conditions. All methods used the same training settings (see Appendix C.2) on the nuScene train set. ΔFlow outperforms Flow4D by ~14% in mean bucket-normalized EPE (0.3652 vs. 0.4233), and by 21% on foreground-dynamic EPE (13.79 → 11.17). This confirms ΔFlow's robustness across three datasets with different sensor specs and environments. We will include the nuScenes results in the final version, and release code to support future evaluation on broader domains.

Table R1: Performance comparison on the nuScene validation set.

W2 & Q3: Computational resources and Real-time Performance Analysis

We apologize if the computational resource analysis is not clear enough. In the current version, the computational resource analysis spans across the paper:

• Section 5.2 presents a detailed breakdown of efficiency as the number of input frames increases.
• Table 3 compares training speed and memory usage with Flow4D, while Figure 3 shows a component-wise runtime analysis, indicating that the Δ scheme adds minimal overhead.
• Appendix D.1 provides a theoretical complexity analysis and quantifies memory savings from our sparse design (Table 5).
• Appendix C.2 reports our training setup (10× RTX 3080 GPUs, 18 hours) and inference speed on a single RTX 3090 GPU, confirming real-time capability.

In the final version, we will try to make it clearer.

W3: Dependence on Labeled Data

We acknowledge that our current experiments use full supervision and note this as a limitation (Lines 298–302). However, the core ΔFlow framework is modular and adaptable to other objectives, such as self-supervised learning.

To demonstrate compatibility with self-supervised learning, we replace the fully supervised loss with the losses proposed in SeFlow. The training result is shown in Table R2, which confirms that ΔFlow can operate effectively without labeled data and even improve existing SSL accuracy.

Table R2: Self-supervised methods, performance evaluated on Argoverse 2 validation set.

The authors have addressed my concerns in the rebuttal, I maintain my rating of weak accept.

Thank you for confirming that our rebuttal, with its new experiments on nuScenes and self-supervised learning, has addressed your concerns.

We kindly encourage the reviewer to consider raising their score from Borderline Accept. If there are further questions, we are more than happy to provide further clarification.

Thanks for the valuable comments! We have addressed your concerns and questions individually below.

W1: Dynamic-Bucket metric for cross-domain evaluation (Tab. 4)

We omitted the Dynamic-Bucket metrics from Table 4 due to space constraints, but we agree they are important for clarity and completeness. We have now included the full results in Table 4a&4b below using the same bucket partitioning as in our main evaluations. DeltaFlow continues to achieve strong cross-domain performance on both dynamic bucketed and three-way EPE. We will revise Section 5.3 accordingly to clarify the metric distinctions in the final version.

Table 4a: Argovsere 2 (2x32-channel) → Waymo (64-channel)

Table 4b: Waymo (64-channel) → Argovsere 2 (2x32-channel)

Q1: Delta Feature Visualization

Please note that Figure 7 visualizes the feature before sending it into the 3D backbone. Due to the different scan patterns, the ∆ scheme captures both static object and moving object features. After being processed by the 3D backbone, the network learns to distinguish consistent motion patterns from spurious or static differences. The resulting feature map ($\mathscr{D}\_{\text{out}}$) shows coherent motion trails on dynamic objects and reduced activation in static areas. For fast-moving objects with little overlap, the feature map exhibits a clear motion trail and has a higher activation than static areas. We will include a $\mathscr{D}\_{\text{out}}$ visualization in the final version for clarification.

Q2 & Q3: Argoverse 2 LiDAR and NSFP Evaluation Setup

For Argoverse 2, we will revise Table 4 to explicitly list the setup as “2×32-beam” to reflect the dual-LiDAR configuration more clearly.

For NSFP, we follow standard practice and run it directly on each target dataset without labels, since it's a test-time optimization method. We'll clarify this setup in the final version.