Spike: how realistic the world can look on the Pixel Tablet, measured — HDRI lighting, photographic surfaces, real trees, a real rider

[mgcronin]

The question this spike answers

How realistic can the trainer game look on the owner's Pixel Tablet, at a sustained frame rate, with three.js as it is? Measured on the device — not argued. #431 (the ADR that takes the world realistic) rests on this, so it is written from numbers rather than from research alone.

A spike: a dated measurement that decides nothing (CLAUDE.md §7). Write-up in docs/spikes/NNNN-realism-on-the-device-floor.md. Refs epic #429.

What is already known (read 2026-09-21)

Device, read over adb and from inside the app's WebView with apps/mobile/tools/webview-probe.mjs:

Device	Pixel Tablet, Google Tensor G2 (GS201), Mali-G710, 7.6 GB, Android 17, WebView 151.0.7922.199
WebGL2	yes — MAX_TEXTURE_SIZE 8192, WEBGL_compressed_texture_astc and _etc present, EXT_color_buffer_float present
WebGPU	navigator.gpu present and requestAdapter() returns an adapter (arm / valhall, max 2D texture 16384)
Viewport	800 × 1280 CSS px at DPR 2 → 1600 × 2560 physical
Frame budget today	the only device ride measured: frame 13 ms, GPU 6 ms at the 50th percentile (validation 0002 §"The baseline") — about 10 ms of GPU headroom at 60 fps

Research (tavily, 2026-09-21; sources in the write-up): the highest realism per millisecond on Mali-class GPUs is image-based lighting from an HDRI + filmic tone mapping, compressed PBR textures (KTX2/ASTC), lighting baked into instanced models, impostor billboards for distant trees, cheap distance/height haze and bloom (~0.3 ms). Expensive at 2560 × 1600: SSAO (~3 ms+), cascaded shadows (~1–3 ms), volumetric clouds, dynamic GI. WebGPURenderer reports on Mali are mixed (driver issues; slower than WebGL for non-instanced scenes) — so the spike measures on WebGLRenderer first, and WebGPU as one extra column only.

Build

A harness page (a new entry in vite.browser.config.ts, and reachable on the tablet — e.g. a debug-only route or a page in the APK's debug build; decide which and record why) rendering one stretch of a real route with:

1. An HDRI sky (Poly Haven, CC0) used both as background and as PMREM environment lighting; ACES or AgX tone mapping (measure both).
2. Photographic road and ground: Poly Haven / ambientCG CC0 asphalt, grass, gravel — KTX2/ASTC compressed, 1K–2K, with a distance blend.
3. Three photoscanned tree species, simplified, with ambient occlusion baked into the vertex colours or texture, plus an impostor for the far band.
4. A placeholder realistic rider: a MakeHuman (CC0 export) body on a CC0/CC-BY-4.0 road bike, skinned, pedalling from bicycle.ts's crank angle. Record its triangle, bone and draw-call count.
5. Distance/height haze and a cheap bloom.
6. Every item a toggle, so each one's cost is read on its own.

All processing through the headless Blender pipeline of #430 (Blender 4.4.3 is available on the developer machine and runs headless with bpy); nothing hand-edited.

⚠️ Licensing. Every asset CC0 or CC-BY-4.0 (ADR 0023), one ASSETS.toml row each (ASSET001–006). ⚠️ #431 has not landed, and it blocks committing realistic assets to the product. So the spike's assets live only on the spike branch (or are fetched by a script at build time and never committed) — the write-up says which. The spike is never merged into the product path.

Measure on the tablet

For each configuration (baseline game; + each item alone; all on; all on at render scale 0.75 and 0.5; all on under WebGPURenderer):

• frame time and GPU time 50th/90th/99th (dumpsys gfxinfo and the harness's own performance.now + EXT_disjoint_timer_query_webgl2 where available);
• draw calls, triangles, texture memory;
• a 20-minute run of "all on" with frame time sampled each minute and the device temperature (dumpsys thermalservice) — the throttling curve nobody has published for this chip;
• a screenshot of each configuration from the device, committed to the write-up (screenshots of our own renderer; ADR 0009 forbids a reference image from another product, not a picture of this one).

Acceptance criteria

• The write-up publishes every number above from the device, with the date, the WebView version and the build.
• It states the realism budget: which of items 1–6 fit together inside 16.7 ms with ≥ 3 ms headroom for 20 minutes, and at what render scale.
• It states what did not fit, with its cost.
• Owner-viewed: the owner has looked at the device screenshots and said which look to pursue (recorded on this issue).
• Write the ADR that takes the game world realistic, superseding ADR 0022 D-1, D-2 and D-7 #431 and Write the ADR for a native world renderer: Godot beneath the WebView, Capacitor and three.js both kept #434 cite it.

Refs #429 · Refs #430 · Refs #431 · Refs #433 · Refs #434 · Refs #247

[mgcronin]

Owner, 2026-09-22, after running the spike (#471, head b34eddb) on the Pixel Tablet: "I tested it. Looks great so far and runs well." The realistic look is the one to pursue. Device figures from the same day are on #471 (all-on holds 60 fps in 30 s windows; GPU p50 10 ms, p90 19 ms; ~355 MiB textures). Still outstanding before this closes: the 20-minute soak and the budget it sets.