30 October–2 November: bake the terrain, show the wait

The work since the previous checkpoint concentrated on keeping play responsive while terrain, shaders and scene ownership change underneath it. Sharing a service was the starting point. The next questions came from actual reconnects, phone memory, slow frames and the gap between a finished download and a playable world.

The shared architecture milestone remains open. The results below describe particular candidate builds, device checks and public game deployments; they do not announce a completed engine release or cumulative integration.

30 October: make the shared owners survive real use

Glasswake passed its two-client reconnect checks with retirement of the old streaming owner before the replacement scene resumed play. Drune exposed a different failure: the new scene prepared terrain around its waiting camera, then the first authoritative vehicle view moved far away. Correcting that preparation order let both clients retain detailed terrain through the original reconnect case. Physical iPad checks with a continuous Mac observer also exercised scene replacement and resumed play.

The visible sky boundary from the previous update was traced to depth lookups using the wrong texture dimensions. Matched Mac and iPad frames at the same reduced render scale showed the correction, with the existing gameplay checks retained.

Phone readiness had several independent gates. The Galaxy S23 eventually connected and completed the two-minute route after unused terrain shader variants stopped being created at startup. Connected proportional-memory snapshots fell from roughly 3.7 GiB in the killed build to about 1.83 GiB in the surviving run. Rendering was still far too expensive. Staying alive established a narrower result than meeting the frame-time target, and later phone traces continued to show serious hitches.

31 October: move terrain work out of the frame

Profiling showed repeated terrain planning, edge construction and lock traffic. A later ground-height diagnostic also caught the rendered surface above the canonical driving surface. Keeping a complete old patch set visible is useful, but a held view that cannot follow the car is a correctness problem too.

The terrain path moved toward baked hierarchies with shared boundaries, worker-prepared cuts and explicit publication of complete replacements. Stable queries could use baked triangles directly instead of repeatedly evaluating transition overlays. Nearby contact detail remained separate from the visual quality ladder.

That first baked representation was much too large to distribute: over 20 GB of expanded mesh data. The compact cook retained baked distant terrain while preparing nearby patches from compact source data. The recorded terrain payload fell to about 145 MB, with integrity checks and reference height comparisons. Those figures describe stored terrain data, not the full game package, total download or memory usage.

The smaller representation also exposed a scheduling hazard. Patch workers could wait for decoding jobs queued behind them. Missing input now defers the patch rather than occupying a worker until another queued job runs. The current complete terrain stays visible while source data becomes ready.

The matching compact-world browser and authority were deployed together early on 1 November. The web quality policy uses sustained slowdown before lowering a step, with slower recovery probes. It targets a usable 30 fps budget; it is not a promise that every device or driving route achieves that rate. Long driving validation and refreshed device packages remained separate work.

The asset-residency article explains why preparation, publication and retirement need different owners. The terrain article follows the related requirement to preserve physical coverage while presentation detail changes.

1 November: distinguish the first frame from finished loading

A browser download could reach 100% while graphics preparation still blocked the world. A traced composition shader took tens of seconds to compile. Startup was changed so initial play could use the existing simpler composition path while optional graphics finished preparing, with real phases and counts visible in the loader.

A later Chrome receipt recorded about 18.5 seconds of preparation before the first gameplay submission. An earlier observation was nearly 77 seconds, but the cache and browser paths differed, so these are not a controlled speedup comparison. Full composition still finished in the background; driving and sustained frame rate need their own evidence.

Xbox needed a different ordering change. The minimal loading view had to exist before expensive scene graphics work. The final observed package submitted its first loading frame in under a second and reported connection after about 49 seconds. Graphics preparation still took substantial time. A subsequent Shipping package with cooked scripts and development tools disabled also connected to the live server; those receipts do not establish manual driving or rendered-gameplay acceptance.

Profile the work that remains

The renderer work continued with CPU, GPU and lock traces. A profiler clock-calibration stall was separated from the game’s terrain hitches instead of being counted as gameplay cost. Later preparation work moved onto persistent workers, shadow command recording overlapped the main view, and large draw queues prepared packets in bounded worker ranges. GPU execution kept its dependency order.

Optimized stationary recordings were much cheaper than Debug captures, but they still contained occasional long frames. A good stationary median does not settle driving stability, presentation waits or performance across devices. The platform note explains why those results remain separate.

Cloud stability needed its own investigation. Camera-relative reconstruction and higher-precision view calculations addressed false ray motion and a history-pixel bias. A later Windows Vulkan resize check found another issue: a full-size output limit silently selected flat clouds when the window grew. Separating composition size from the bounded ray-march and history buffers kept volumetric clouds active at both 1280×720 and 3840×2160 in the checked build.

2 November: a denser island is a new candidate

The next world began as a separate LibreTerrain island draft: connected coastal and inland roads, gentler beaches, sharper uplands and more varied small water bodies. The highest-resolution export attempt failed before producing files. The following 16K export completed, retaining 16,385 samples per side at 37.5 cm spacing. The first game import used a shared 75 cm grid for rendering and collision while retaining the finer source.

Cook checks compared imported driving heights with the exported source and checked shared edges and hierarchy levels. The island reached a local connected driving session on 2 November, but discontinuous-looking river pieces were still being investigated at this checkpoint. The water and banks need to read as one continuous channel.

The public web update deployed on 1 November deliberately retained the preceding world. The new island was outside that release, and local driving does not turn it into a finished public terrain update. The current game remains available at Drune, alongside Glasswake, while cumulative review, remaining performance work and device-specific acceptance continue.