# Decision: coherent vehicle presentation and native 60 FPS evidence Status: accepted by native validation, 2026-09-24. Action: publish the verified candidate and retain the independent timing and visibility gates. ## Context and measured baseline The user requests nearly imperceptible stutter, two chase views, live Jev terrain sabotage and an end-to-end whitepaper update. This extends the accepted `staged-final-r2` baseline; its source/binary hashes and footage remain in `docs/evidence/driving-continuous-20260923`. Server authority, durable terrain activation, collision acknowledgement and the finite driving watchdog remain unchanged. The owner is client presentation behind RenderSnapshot. The baseline's 754/755 active captured frames show a camera/body mismatch up to 0.0764/0.0785 m. Camera extraction ran before smoothing, body extraction after it. Capture intervals were median 33.15/33.24 ms, maximum 41.39/40.56 ms. Its 200 ms driving observations cannot rule out shorter stutters. Vehicle transforms used exponential pursuit of the latest 20 Hz pose; wheels used unsmoothed latest solver measurements. A stable FPS alone does not prove stable apparent motion. ## Alternatives and selection | Option | Benefit / cost | Decision | | --- | --- | --- | | Keep pursuit, collect more coarse observations | No added latency; cannot remove the demonstrated camera mismatch or staircase wheel motion | Retain baseline, supersede presentation | | Sample a small coherent chassis/wheel history once before camera and draws | Removes pursuit pulses for steady snapshots; adds a bounded 100 ms receive-time presentation delay; no wire or physics change | Implement | | Client vehicle prediction or faster authoritative simulation | Could reduce latency, but requires reconciliation and new physics/protocol evidence | Outside this corrective change | Mirror retains at most 12 samples per replicated vehicle. Only accepted ordered wheel frames paired with the current authoritative chassis enter the history. The client linearly interpolates positions, slerps orientations, and interpolates suspension/steering/wrapped wheel spin at the same delayed time. It does not extrapolate past the latest real sample. Teleports over three metres, changed incarnations, gaps over 250 ms, recipe replacement, despawn and Welcome discard history. Frozen visual diagnostics preserve their frozen pose. Receipt-time jitter is still possible; this is not server clock synchronization. The first complete 60 FPS acquisition exposed another concrete interaction: the distant compact-move lane used 5 Hz while full quaternion updates used 20 Hz. Wheel frames require the client to know the exact body version, so the same car alternated between those cadences as its rotation settled. Bravo's publication jumped from physics sequence 2105 to 2108; its latest sample aged to 146 ms and the 100 ms presentation buffer ran dry. Visible vehicles now use each existing server tick for compact translation as well. Ordinary distant objects retain 5 Hz, and AOI admission, frame/byte budgets, fairness and slow connection fuses are unchanged. This adds bounded traffic for visible moving vehicles, not new interest or simulation authority. A replication regression checks eight consecutive far-car updates against two ordinary-object updates. The end-to-end audit also reproduced a separate encoder defect. The old concat manifest specified real durations, but each PNG still used FFmpeg's default 1/25-second time base. Distinct images 3 and 4 both decoded at PTS 0.12 s; FFmpeg reported non-monotonic timestamps. Manifests now set each image demuxer's time base to 1/1,000,000 second. The same inputs decode at 0.102 and 0.133 s. Paths remain validated local basenames, and only these generated manifests use the required `-safe 0`. A real-FFmpeg regression proves seven distinct images retain their sub-40 ms timestamps and pixel hashes. Both output encoding stages now preserve the requested recording FPS instead of imposing 30 FPS. ## Execution and acceptance The engine has several clocks; stability must survive every boundary: ```mermaid flowchart LR A[Authoritative physics / 20 Hz world tick] --> B[Bounded AOI replication / exact body version] B --> C[Mirror / coherent chassis and wheel history] C --> D[100 ms receive-time interpolation] D --> E[One presented pose / camera, body and wheels] E --> F[RenderSnapshot / native presentation] F --> G[60 Hz absolute capture slots / real timestamps] G --> H[Microsecond image time base / 60 FPS video] ``` The held pure-terrain checkpoint and collision-preparation path remains upstream of A. Client buffering cannot authorize a crater or keep a stalled simulation moving. Native frame cadence, authoritative progress, presentation starvation and encoded timestamps are checked separately rather than collapsed into FPS. Client validation passed 432 unit tests (two pre-existing ignored tests), and all 42 replication tests passed, including the new far-vehicle regression. Twenty-five focused JavaScript tests pass, including the actual FFmpeg time-base regression and fail-closed smoothness gates. Unit tests cover steady 20-to-60 Hz motion, suspension/spin coherence, packet starvation, recovery, duplicate frames, teleports, incarnation replacement and the history bound, car occupancy changes and animal-rider preservation. Mirror lifecycle and capture tests pass. The subsequent diagnostic-title opt-in change was compiled and is covered by the final native recording. Record 50 seconds per viewport at native 60 FPS, 1280x720 each. This is 3,000 frames and about 10.3 GiB raw pixels per client, below the existing 3,600-frame, 14 GiB runner and 16 GiB native staging limits. No resource ceiling is raised. The output preserves real timestamps at 1.0x and uses no motion interpolation. The dual-view runner allows a 20-second cold scene warmup before either fixed recording begins. The drivers and saboteur still start only after both recordings have acquired ten seconds; this changes loading pre-roll, not the measured driving window or the full-session no-gap requirement. Occupied cars omit the current driver at scene extraction before all mesh, animation, weapon and shadow paths. Occupancy is re-evaluated each frame; exit, vehicle despawn or driver replacement restores the old actor. Authoritative entities and Jev controls remain intact. Animal mounts retain their riders. The native sidecars name omitted drivers and reject submitted driver meshes. New native sidecars retain every intervening presented frame's sealed start-to-start interval and CPU time, including capture/readback frames. A 4,096-row buffer records overflow explicitly; no synchronous per-frame file I/O is added. Acceptance checks the entire driving window, not selected explosions: - Existing full-session no-gap, complete-car, live-provider, collision and continuous-driving gates remain mandatory. - Both native rates at least 59 FPS; captured interval p99 <=25 ms and max <=33.334 ms; all presented intervals p99 <=16.667 ms and max <=33.334 ms. - Camera/body position difference <=0.00001 m in every active native frame. - Coherent wheel/body samples present; no interpolation starvation during the active window, no telemetry overflow, contiguous serials and time boundaries. - No missing raw frame evidence. Replay/seek checks and bilingual production whitepaper publication use the existing Worker/assets path. Failures remain retained and require a fix or an explicitly inconclusive result; these thresholds are not relaxed after a failed run. Local evidence does not establish production network latency or universal hardware performance. ## Outcome The accepted native run is `target/dual-driving-20260923-smooth60-r5`. Both complete sessions have 3,000 frames, zero gaps and completed per-frame image analysis. Each active window contains 1,535 capture frames; all 4,628 / 4,541 intervening presented intervals are contiguous and measured. Native active rates are 59.9997 / 60.0012 FPS. The separately exported public receipt binds this candidate to exact source, binary, report and video hashes. | Measured active window | Alpha | Bravo | | --- | ---: | ---: | | Presented interval p99 / max (ms) | 8.375 / 10.326 | 8.390 / 14.112 | | Capture interval p99 / max (ms) | 21.459 / 23.742 | 21.471 / 24.359 | | Camera/body position difference (m) | 0 | 0 | | Starved vehicle samples | 0 | 0 | | Longest authoritative observation gap (ms; nominal 200) | 215 | 215 | | Sampled midroute physics stall / pose stop (ms) | 0 / 0 | 0 / 0 | | Authoritative progress (seconds) | 25.202 | 24.598 | Four live Jev crater activations commit. Collision installation peaks at 0.978 ms; checkpoint upload still reaches 370 ms without stopping the cars. Every active capture verifies mounted-driver omission, coherent wheel/body samples, and the encoded chassis model matrix. Native images were inspected for the requested empty pickup cabin/bed and full-car chase framing. No frame interpolation or speed-up is used. These are local measured bounds, not a universal OS, GPU or network guarantee. The 100 ms presentation delay remains explicit. Validation logs are `target/smooth-driving-client-final-tests.log` (432 passed, two ignored), `target/smooth-driving-replication-tests.log` (42 passed), and `target/smooth-driving-js-final-tests.log` (25 passed including real FFmpeg). The final client build, formatting and diff checks pass. The task-specific Cargo cache was cleaned after confirming no process used it, freeing 13.6 GiB; tested runtime binaries remain in `target/smooth-driving-binaries`. Executable native gates: `node scripts/authoring/driving-smoothness.mjs target/dual-driving-20260923-smooth60-r5`, plus the recorder's existing `verifyDualRecording` and `verifyDualContinuity`. Public export remains gated on successful full video decoding, the unchanged gameplay gates and asset size. The rejected attempts below are retained separately and are not used as passing evidence. The first attempt (`smooth60-r1`) failed before opening the native viewer because the build omitted `retained-presentation-wire-v1`, which the existing experimental Catalog V2 demo requires. No gameplay or performance verdict was produced. The replacement is built and tested with both existing opt-in features. `smooth60-r2` acquired 2,998/3,000 and 3,000/3,000 slots and was rejected. The 29.09-second active window had five committed attacks, zero camera/body offset, but three Bravo samples starved and Alpha lost two slots. Alpha's longest presented interval was 23.34 ms despite render CPU under 10 ms at that point; both clients show a simultaneous scheduling tail. Extra update and full render timings are added to separate event-loop time from renderer time on the next run. The source data cannot yet attribute that tail to one OS/API call. Both complete raw pixel stages were sealed before the known-failed offline PNG analysis was stopped. Raw frames, frame metadata, outliers and the explicit rejection remain retained; no video from this run is published. `smooth60-r3` validates the cadence fix over 1,734 active capture frames per view: no active slot gaps or starved interpolation; all-frame p99 8.81/9.64 ms, max 18.71/18.85 ms. It is still rejected because the full sessions lost 20/17 slots, mostly in cold startup before driving. Both raw stages were sealed before stopping offline PNG analysis. The diagnostic is retained in the run directory. Outer update timings stayed below 0.26 ms in the active window; full-render and outside-render tails are now separately observable. This does not prove an OS cause for the remaining tails. The replacement also includes the requested mounted-driver omission and longer explicit cold-loading pre-roll. `smooth60-r4` acquired 3,000/2,999 frames and is rejected for the missing Bravo slot 478 before driving. Its preceding frame spent 25.64 ms in the full render call although the instrumented render phases totaled only 5.96 ms. Native title updates occur in that remaining post-Present work and winit calls synchronous `SetWindowTextW`. Periodic title mutation is now opt-in with `--log-frame-stats`; the regular FPS HUD is unchanged. This removes avoidable synchronous shell work, but the timing does not by itself prove that all 19.68 ms was inside that API. The mounted driver IDs were omitted in the raw native reports. Both raw stages are retained; this candidate is not published.