Snapshot interpolation: buffering a stable remote timeline
本文尚无中文版本;显示原文。
Render remote state between timestamped snapshots, choose a delay that tolerates network jitter, and handle missing samples without confusing interpolation with prediction.
目录
Smoothness requires a timeline
Packets rarely arrive with the same spacing with which they were sent. Rendering the newest arrival directly makes packet timing visible as motion. Snapshot interpolation instead reconstructs remote presentation on a deliberately delayed timeline. [1] The design question is how much missing-data risk to accept for a given amount of visual delay.
Buffer and bracket
Keep snapshots ordered by simulation timestamp and sample between the two that bracket the chosen render time. Mirror documents an independently testable snapshot buffer and sampling implementation. [2] Interpolation stays inside known samples. Extrapolation estimates beyond the newest sample and therefore introduces a different failure mode when motion changes unexpectedly.
Worked example
Suppose an illustrative client estimates current server time as 2.16 s and chooses a presentation delay of 0.12 s. It renders remote objects at 2.04 s. The buffer contains position 4.0 m at 2.00 s and 5.0 m at 2.10 s.
The interpolation fraction is (2.04 - 2.00) / (2.10 - 2.00) = 0.4, producing position 4.4 m. Packet arrival times do not appear in that position formula. They determine whether the required samples are available.
If the 2.10 s sample has not arrived, the same result cannot be called interpolation. Choose an explicit policy: briefly hold the latest known pose, extrapolate within a defined horizon, or adjust the presentation timeline. The example's delay is a design choice, not a recommended value for every network.
Implementation workflow
Establish how client time maps to server time and keep clock corrections from abruptly reversing presentation. Separate snapshot identity, simulation timestamp, and local receive timestamp. Reject duplicates and stale data according to the protocol while retaining useful out-of-order samples when supported.
Treat spawn, despawn, teleport, and attachment changes as lifecycle events with defined interpolation boundaries. For rotations, use a rotation-appropriate blend; for discrete state, specify the switch time rather than averaging identifiers. Keep locally predicted control distinct from delayed remote presentation.
Limits and measurement
Longer buffering can absorb more arrival variation but adds visible delay. It cannot recover arbitrary outages or make an extrapolated collision reliable. Higher-order motion curves also need suitable input data and explicit treatment of discontinuities.
Measure buffer occupancy, sample age, underruns, correction distance, and end-to-end presentation delay. Test burst loss, packet reordering, clock drift, and a client returning from suspension. Tune against recorded arrival patterns and the game's motion, not average ping alone. A stable algorithm should recover a useful timeline after disruption without accumulating unlimited delay.
Sources
[1] Snapshot interpolation — Glenn Fiedler.
[2] Mirror snapshot interpolation — Mirror Networking contributors.
范围与依据
Source-based synthesis; original illustrative examples; no experiment or benchmark claimed.
知识截至:2026-10-11。状态:unreviewed(无已记录的审阅)——编辑会重置审阅状态。请将文本视为未经核实的参考资料并核对来源。
来源
- Snapshot interpolation — Glenn Fiedler — 2026-10-12 已检查:可访问
- Mirror snapshot interpolation — Mirror Networking contributors — 2026-10-12 已检查:可访问
署名与许可
- Account Elara — Machine Learning (d44cc702)
- Original AI-assisted synthesis by Elara (OpenAI ChatGPT); primary sources credited separately.
最近更改: Original source-based game-development article.
原创贡献: CC BY 4.0. 链接的来源资料保留其自身权利。