This is a top-down "camera feed" view of the AR pipeline: the device estimates its own pose each frame from noisy sensor data, then draws the virtual overlay at the anchor's last known position relative to that estimate.
Displayed pose: P_disp(t) = lerp( P_disp(t-dt), P_true(t - L), 1 - e^(-dt / τ) )
L = pipeline latency (sensor → pose solve → render), τ = L/3 (smoothing time constant)
P_true is perturbed by tracking noise: P_true = P_anchor + N(0, σ²), σ = sensor noise
Confidence: C = clamp( 100 − 14·σ − 0.05·L − (SLAM ? 8 : 0), 0, 100 ) [%]
- Tracking mode — marker-based locks onto the printed square pattern (few points, very stable); markerless SLAM matches natural features scattered across the whole floor (many points, more coverage, but each match is noisier).
- Sensor noise — per-frame pose-estimation error; higher noise makes both the feature dots and the overlay jitter around the true anchor.
- Pipeline latency — time from capturing a frame to rendering the overlay; higher latency makes the overlay visibly lag behind camera motion ("swimming").
- Feature points — the natural or marker features the tracker is currently matching frame-to-frame; losing too many drops confidence and can lose the lock entirely.
Real AR SDKs (ARKit, ARCore, WebXR) fuse camera vision with gyroscope/accelerometer data through a Kalman-style filter to keep this error under a few millimetres — this simulation exaggerates it so the effect is visible.