# Snapshot Interpolation
Source: https://gafferongames.com/post/snapshot_interpolation/
Author: Glenn Fiedler | Date: 2014-11-30 | Series: Networked Physics

## When to use
If simulation is not deterministic or player counts grow past lockstep comfort, send **snapshots** of visual state. Receiver does **not** run the simulation; reconstructs a visual approximation.

## Snapshots
Example CubeState: interacting, position, orientation. Include 16-bit sequence; discard older-than-latest on receive. Naive render-latest still hitches because Internet jitter clusters packets.

Lower send rate (e.g. 10 pps) cuts bandwidth but looks choppy without buffering.

## Interpolation buffer
Hold snapshots briefly so statistically you have both current and next sample. Trade added latency for smoothness. Linear interp of position shows 1st-order discontinuities; katamari attachments can "pulse" through the parent cube.

## Hermite interpolation
Send linear velocity; Hermite spline matches positions **and** velocities at endpoints → smoother. Orientation: slerp usually enough; angular velocity often unnecessary for cubes.

## Packet loss
Snapshots are time-critical but **not** requiring reliability. Never TCP. Skip lost snapshots; interpolate toward more recent ones in buffer. Rule of thumb: buffer delay ≈ 3× send interval for 2–5% loss (survive two losses) + small jitter margin. At 10 pps → ~300ms + ~50ms = ~350ms. Extrapolation can cut delay but fails badly for nonlinear rigid-body collision (floor tunneling, spring mispredict, katamari tangent vs rotate).

## Reduce delay
Increase send rate: 30 pps → ~150ms buffer; 60 pps → ~85ms. Requires bandwidth optimizations (next article).