The previous update stopped before the evening’s integrations. Glasswake’s progressive world delivery and the terrain architecture milestone subsequently passed their cumulative reviews and merged. The new refactor is a separate, ongoing piece of work. Passing checks on its individual slices does not mean the whole milestone is accepted.
The direction is practical: move reusable mechanisms into OmiLith, then exercise them through real games. Game-specific components and substantial native operations remain in C++, exposed through reflection where useful. Small Lua modules handle suitable gameplay rules and orchestration. Sharing an engine should make ownership clearer while leaving each game room to behave differently.
One lifetime for refinement
Both Drune and Glasswake now exercise the shared mesh-refinement owner. Games still choose their detail ladders, priorities, retry policy and budgets. The engine coordinates requests, decoding, publication and cancellation against the lifetime of the scene.
That boundary matters when a player moves away. Stopping a decoder while leaving its browser download active is incomplete cancellation. Restoring coarse detail also needs to retain a real, admitted fallback, rather than merely increment a counter. The new checks distinguish assets already resident in the scene from new publication events.
Drune passed native and browser driving checks through this path, followed by interactive cancellation and coarse restoration. Glasswake’s native checks observed fine detail, cancellation, coarse restoration, and refinement again after returning to the same area. Scene replacement and reconnect are still separate qualification work; a successful camera excursion does not establish that an old owner retires correctly when the scene itself changes.
Prepare a world, then publish it
Terrain publication is becoming shared machinery too. Workers prepare immutable results; bounded staging admits the candidate over several frames; a complete visual cohort then replaces the previous one. A cancelled or rejected candidate leaves the current preview usable. This visual transfer does not make a separate physics handoff jointly atomic.
Terrain Workshop exercised cancellation, replacement with a smaller graph, and preservation of unrelated scene edits. Its terrain, grass and water changed together. A scene edit during staging also exposed a useful distinction: an otherwise valid prepared result may need to be retried against newer scene state, rather than treated as a fatal failure.
Drune’s integration initially exhausted the scene’s asset slots. The correction reuses admitted terrain slots before allocating new names. Repeating the original stress run passed without increasing the asset cap. That resolves the observed allocation failure; it does not close the separate triangle-budget and camera-lag findings.
The residency article explains the underlying fallback and ownership problem, while the terrain note follows the distinction between stable physical coverage and presentation detail.
Keep small scripts small
Drune’s driver rules now use a shared Lua module loader. The offline producer checks the complete module catalogue and cooks a single Shipping package. The Shipping runtime excludes the compiler and analyzer. Native game components and operations retain their existing ownership.
A real reload check changed the module’s beacon-placement behavior, rejected an invalid initializer while preserving the last working program, then restored the original rules. That is stronger evidence than a successful cook alone: the game has to keep a valid program when a development edit fails.
Audio follows a similar separation. OmiLith owns shared device, graph and recording lifetimes; Drune keeps its mixer and cues. Native driving and a normal Mac Shipping recording exercised the shared output, with decoded game audio. The browser reached gameplay and completed a recording through its UI, but decoded audio verification remained pending at this checkpoint. Native success is not a substitute for that missing browser evidence.
Measure less work honestly
Vulkan startup now defers optional rendering programs until requested. The controlled comparison showed fewer startup programs and a smaller new application-cache payload. It did not establish a faster join, and it did not explain an earlier long startup stall.
WebGPU preparation also became incremental so the client could continue processing its connection while graphics programs compiled. A later browser run reached real gameplay and exported its report. Preparation time remains an optimization target; a loading screen that keeps the connection alive is progress, but it is not the same result as faster readiness.
Mac and physical iPad checks passed the scoped driving case after the Simple water and terrain-preparation corrections. Terrain catch-up, triangle budgets and visible sky defects remain open. Wider device acceptance and the final cumulative review are still ahead. The platform article explains why each of these gates needs its own evidence.
The creative app is still in review
PanoPainter’s release review added application checks for export timing, text baselines, layout admission and versioned storage. Focused Mac, Windows and Linux results are recorded, while the candidate remains under review with remaining release gates. This is development progress, not an announcement of a new public release.
Have a thought or a question?
I'd love to hear it. ↗