Skip to content
Changelog

What shipped, when. The honest version.

Every release, every fix, every breaking change. No "various improvements," no "performance updates" — the specifics or nothing.

  1. v1.18May 12, 2026#
    Shipped

    Stacked-floor 3D view, now the default

    The public viewer now ships a stacked-floor 3D view by default. Floors lift apart on scroll, the active floor stays sharp, and the others drop to a stylised silhouette so the visitor doesn't lose their place.

    Existing embeds inherit the new view automatically. The 2D top-down view remains available — append ?view=2d to the viewer URL, or toggle in the corner control. Per-floor selection still works the same way.

    The biggest behavioural difference: the floor switcher now lives in the bottom-right corner instead of a fly-out from the left. Operators with a kiosk in production should re-test their touchscreen flow once before promoting — the move is intentional but the muscle memory is real.

    Performance is up across the board: median TTFB dropped from 380 ms to 270 ms (p75), and the viewer now hits 60 fps on the five-year-old phone we keep in the test rig for exactly this reason.

  2. v1.17April 28, 2026#
    Improved

    CAD ingestion 2× faster

    CAD ingestion is roughly twice as fast. The median time-to-first-map dropped from 16 minutes to 8 minutes on the reference venues we track; the worst case (the 1970s hospital pavilion we use as a torture test) went from 47 minutes to 23.

    Most of the gain came from parallelising the wall-snap pass — previously serialised because of a stale assumption that snap regions could overlap. They can't, once the parser's tolerance pass has run. Removing the serialisation lock got us 40% on its own.

    The remaining 60% came from a Rust port of the room-inference algorithm, which was previously the slowest stage on any floor with more than 300 rooms. The TypeScript fallback is still there for environments without the native binary — set MINDDIGITIZE_NATIVE_INFERENCE=false if you need to pin to JS.

    Parsing reports are unchanged in format. Existing tooling that consumes the report JSON keeps working.

  3. v1.16April 15, 2026#
    Added

    Two new accessibility profiles: stroller, low-vision

    Two new accessibility profiles ship today: stroller and low-vision. Both join the existing wheelchair and no-stairs profiles.

    The stroller profile prefers wide corridors, avoids tight turns, and weights edges through escalators as effectively impassable. The low-vision profile prefers edges with audio cues at junctions, weights edges through low-ambient-light zones higher, and avoids edges that require reading wayfinding signage to confirm direction.

    These are query-time weight sets against the existing graph, not new maps. Operators don't need to edit anything — the new profiles are immediately available in the viewer's profile selector and in the routing API.

    Custom profile authoring (defining your own weight set for a non-default audience) ships next month. Until then, the four defaults cover most cases and are tunable per venue if needed.

  4. v1.15.1April 2, 2026#
    Fixed

    Race condition between closures and in-flight routes

    Fixed a race condition where a corridor closure flagged within 200 ms of an in-flight route request could be missed by the router, returning a path through the closed edge.

    The bug was hard to reproduce — it required closure propagation and route solving to land in the same async tick on the routing worker. We caught it in production at a stadium during pre-event setup, where the operations team flagged a section closure and the help desk got two routes through that section before the third one updated correctly.

    The fix moves closure-flag updates into a synchronous pre-step on every route solve, costing roughly 1.2 ms per solve. The router's p95 went from 28 ms to 29 ms. We'll take it.

    Routes returned before the fix landed are not affected retroactively — the viewer always polls for closures every 500 ms regardless, so any visitor mid-walk on a stale route still got the re-route within half a second.

  5. v1.15March 18, 2026#
    Breaking

    Routing endpoint renamed: find-path → route

    The routing API endpoint moves from /v1/maps/:id/find-path to /v1/maps/:id/route today. This is a breaking change for direct API consumers — the old path now returns 410 Gone with a JSON body pointing to the new one.

    We held this rename for three months specifically so it could land alongside the v1.15 release, which also dropped the legacy single-floor-only response shape. Together they justify the breakage: the new endpoint returns multi-floor routes in the same shape regardless of source/target floor, removing a long-standing inconsistency.

    Migration: rename the path. The request and response shapes are otherwise identical. Customers using the @minddigitize/sdk package received a deprecation warning four versions ago; the SDK 2.4 release shipped today removes the warning and the old path entirely.

    If you're embedding the public viewer via iframe, you're not affected — the viewer talks to the API on your behalf and has been updated.

    We'll keep the 410 response in place until 2026-10-18 (six months). After that, the old path returns 404.

Your story, next

Send us a CAD file. We'll send back a working viewer.

20 minutes. We ingest your floor plan live and you walk away with a public viewer of your building, shareable as a link. Your next case study, on us.