快照压缩与增量编码

提高快照率以降低插值延迟，必须把每快照比特打下来：有界量化、四元数「最小三分量」、静止省略，以及相对对端已确认基线的增量编码。Source 的 delta snapshot 与 ack 跟踪是同一家族的工程实现。

插值缓冲大致随「发送间隔」放大。要把延迟从数百毫秒打到可玩，需要 30–60 Hz 快照；未压缩时对象稍多就会上到 Mbps～十几 Mbps。目标带宽可设在约 256 kbps 量级做压力测试。（Snapshot Compression；Snapshot Interpolation）

字段	思路	量级例子（Gaffer 立方体场景）
朝向	Smallest three：单位四元数丢最大分量（2 bit 索引），其余量化到 ±1/√2；可强制 w≥0 省符号	128 bit → ~29 bit
线速度	有界量化；「静止」1 bit 省略；高发送率下甚至整字段不发	可从 96 bit 降到 0
位置	世界有界 + 毫米级量化	96 bit → ~50 bit

优化顺序宜从最大字段做起；最好的优化是证明某字段不必发。（Snapshot Compression）

发送「快照 N 相对基线 B」。接收端持续 ack「我有的最新快照」；发送端把基线推进到约 RTT 之前的那份。连接初期无基线：用「相对双方已知初态」标志，或先可靠下发一份非增量引导块。（Snapshot Compression）

未变化物体：1 bit「未改」。也可只发变更列表 + 物体索引；当变更很少时索引更省，变更很多时 bit 向量更省——可按帧择优。相对索引（差分物体编号）、相对位置/朝向的多档小/大范围，能继续抠比特。算术编码相对手工 bit-packing 仍可能再赢一截（约 25% 的案例）。

Source：服务器发送相对「上次已确认更新」的变更；重度丢包或开局才拉全量（cl_fullupdate）。（Source Multiplayer Networking）

flowchart LR
  S["发送端"] -->|"快照 N Δ 相对 B"| R["接收端"]
  R -->|"ack 最新快照 M"| S
  S -->|"更新基线 B ← M"| S

上图：基线跟随 ack 滑动，稳态落后约一个 RTT。

压缩解决「每个对象多少比特」；复制图与相关性解决「哪些对象根本不进快照」。两者叠用。

有损量化要在本地也走同一量化，以免预测/校验和漂移。相对朝向的收益往往小于相对位置；可用角速度预测改进。切勿在未压带宽前盲目加发送率——先测 choke/loss。

出处