Waypoints get their first AR-ready models
A quiet week for the walking app itself, but the pipeline behind it took a real step forward: the 3D models historians have been building all along can now become something the app could eventually show you in AR.
For historians: 3D models become AR-ready
RealityKit — the framework Story Trail Walk would use to show a 3D model in the real world through your camera — can’t read the glTF/GLB files SAM3D generates. It only reads USDZ. Until this week, that meant a historian’s 3D model had a ceiling: viewable in the workshop, never in AR.
That ceiling is gone. The 3D backend gained a GLB→USDZ conversion tool — chosen only after a real side-by-side test against the obvious alternative, Blender’s own USD exporter, which turned a 93MB model into a bloated 437MB USDZ by embedding raw texture data. The tool that shipped instead (a patched version of Apple’s own WWDC19 converter) packed the same model down to 66MB, smaller than the source, and passed two independent ARKit validity checks.
Suburb Historian now wires that up directly: a “Generate AR asset (USDZ)” button on a waypoint’s 3D facet, a health indicator, and an amber staleness warning if the underlying model gets edited after conversion. It’s deliberately a button, not something that happens automatically the moment a model is generated — SAM3D’s raw layouts are known to need a human pass in the model editor before they’re trustworthy, so nothing gets baked into an AR asset until a historian has actually looked at it. Once generated, the USDZ pushes straight through to Story Trail’s backend alongside the existing 3D model, so the file is sitting there waiting the moment the walking app is ready to load it.
For historians: waypoints research their own surroundings
The “nearby activities” list — things worth doing near a stop, previously a purely manual add-your-own list — now researches itself. A new pipeline step queries real map data in a 100-metre radius around each waypoint’s own location and writes candidate activities straight in, and a matching “🔍 Research activities here” button lets a historian re-run that lookup on demand for a single waypoint. Along the way, activities also got promoted to their own facet tab with a count badge, instead of being buried inline under the approach story where it was easy to miss.
Under the hood
A real data bug got tracked down and fixed at the source: push_waypoint was silently omitting a waypoint’s own References facet from what got sent to Story Trail, so the walking app was falling back to a stale, trail-level copy of the sources instead — a leftover from an older export path that copied one set of references onto every waypoint in a trail. It was reported by someone actually using the app and noticing the same references showing up at both levels. The fix is live, and the 54 published waypoints (of 141) caught with duplicated references have been cleared back to null so they’ll pick up a curator’s real edits the next time the waypoint is saved.