zhonghm

The Bay Area digital twin runs in a browser now. Same C++ as the desktop build, compiled to WebAssembly and drawn through WebGPU. Real terrain, procedural buildings, the landmarks, replayed traffic, a sun and moon on the real ephemeris, and a car you can drive. Desktop Chrome for now. bayarea-web.pages.dev Getting it there was a data problem, not a graphics problem. My first measurement, three weeks ago: one view of the Bay meant fetching 1.7 GB and holding 4.2 GB in memory. A browser caps WebAssembly at 4 GB. The port downloaded for five minutes, then crashed before it drew a pixel. The stack was the easy part. The world logic moved into a GPU-free C++ library both builds share. Shaders are written once in GLSL and translated to WGSL with naga; every one compiles in Chrome, none ported by hand. Loader threads fetch tiles with HTTP Range requests from Cloudflare R2. The fix was loading by distance, not by region: full detail within a kilometer, major roads out to three, the traffic graph tiled by radius instead of loaded whole. Then zstd on what was left. Bytes to a settled view: 1.7 GB down to about 170 MB. Memory: 4.2 GB down to about 2 GB. Then batching: nearly 4,800 requests cut to a third, and the first view on an 80 ms link went from 181 s to 31 s. And the frame rate: street level went from 4 to 17 fps to 60, standing and driving, on my desktop. Every release renders 58 golden scenes in Chrome and scores them against the desktop build. The arrival view scores 0.99 on SSIM, an image-similarity measure where 1.0 is identical. I directed the work. Claude Opus 5.5 did the heavy lifting, from the port to this video. Map data © OpenStreetMap contributors (ODbL). Land cover: ESA WorldCover 2021 (CC BY 4.0). Terrain: USGS 3DEP and NOAA. #WebGPU #WebAssembly #cpp #gamedev #OpenStreetMap