The Metaverse Failed. Augmented Reality Didn't.

Why spatial computing might find its second act in science, education, and low-budget development For a stretch of 2021 and 2022, it looked like computing was about to move somewhere else entirely. Meta rebranded around the idea, Microsoft bet HoloLens and Mesh on it, and a wave of startups raised on the premise that avatars and virtual land were the next platform shift - on the scale of mobile after the web. Reality, the pitch went, was just one interface among several, and not necessarily the best one. Then the capital dried up, the headsets stayed in drawers, and generative AI took over every keynote slot the metaverse used to occupy. Augmented reality didn't get a rebrand or a eulogy - it just went quiet. That quiet turns out to be useful. Once you strip away the promise of replacing reality wholesale, what's left is a narrower, more tractable engineering problem: how do you register digital content to physical space accurately enough, and cheaply enough, that it's worth doing at all? The part of the metaverse pitch that never made sense Virtual worlds assumed people wanted an alternative to physical space. Most contexts where technology actually gets used - classrooms, labs, hospitals, workshops, museums - don't work that way. Nobody wants to put on a headset to replace a dissection table; they want something layered on top of it. That reframes the interesting question. Not "what if we replaced the physical world," but: what's the minimum viable way to attach information to a specific point in physical space, and have it stay there as the user moves? That's a tracking and rendering problem, not a platform problem. A chemistry student manipulating a rotatable molecular model gets more out of six degrees of freedom on a real desk than out of a mouse-drag on a 2D projection. An anatomy student benefits from a heart they can walk around. None of that requires an immersive world - it requires accurate spatial anchoring and a rendering pipeline that runs on a mid-range phone. Where 2D diagrams actually break down Most science pedagogy is still built on projections of 3D structure onto flat media - textbook diagrams, static slides, pre-rendered video. That's a reasonable compromise when the alternative is expensive lab equipment, but it has a specific failure mode: anything where spatial relationships carry information (protein folding, orbital mechanics, stratigraphy, tensor fields) gets flattened into a representation that hides the thing you're trying to teach. AR doesn't fix pedagogy by itself - plenty of AR experiences are gimmicks with no learning value. What it changes is the input: instead of inferring 3D structure from a 2D projection, you register the 3D object in your own frame of reference and let parallax and occlusion do work that annotation used to have to do manually. AstroFlow: what building one actually involved We tested this directly with AstroFlow, a university project combining WebXR-based 3D visualization with device AR, covering astronomical structures and human anatomy. The interesting part wasn't the final experience - it was how little specialized infrastructure the pipeline needed. Pipeline: research → architecture → UI design → prototyping → asset production → implementation → animation → deployment → maintenance. - Architecture. We evaluated Microsoft's Mixed Reality stack early on, mainly to understand session lifecycle and anchor persistence models, before settling on a web-first approach for distribution reasons (more on that below). - Design. Standard Figma wireframing before touching any 3D tooling - worth doing before AR work specifically, because interaction design in 3D space is much harder to iterate on once you're inside a headset or camera view. - 3D asset pipeline. Blender for modeling, retopology where needed, and export to glTF/GLB - the format WebXR and Three.js actually consume efficiently. Poly count and texture size matter more here than in almost any other context, since everything has to fit a mobile GPU's frame budget alongside camera passthrough and SLAM tracking. - Implementation. WebXR Device API for session management and hit-testing, ARCore underneath on Android for plane detection and pose tracking, Three.js as the rendering layer on top. - Animation/interaction. ZapWorks for marker-based tracking and interaction logic on segments where full SLAM wasn't necessary. - Deployment. Vercel - meaning the AR experience is a URL, not an app store submission. - Maintenance. VS Code and GitHub, nothing exotic. None of this needed a dedicated AR lab. It needed a laptop, a phone with ARCore support, and a willingness to read WebXR spec documentation. Why the toolchain is a bigger deal than it sounds A few years ago, "building AR" meant native development against ARKit or ARCore, a computer vision background helpful for anything beyond marker tracking, and either Unity/Unreal or a hand-rolled OpenGL pipeline. That's a real barrier - it selects for teams with existing 3D engineering experience. The WebXR Device API changes the economics, not because it's more powerful than native SDKs (it isn't - you lose some low-level camera and depth API access), but because it collapses distribution to a browser link. navigator.xr.requestSession('immersive-ar') , a hit-test source, an anchor, and you have a session without an app store review cycle. For education specifically, that's not a minor convenience - it's the difference between "install this app before Tuesday's lab" and "click this link." Combine that with Blender's glTF export pipeline (which handles Draco compression and PBR material export cleanly enough now that most beginner mistakes are poly count, not format), and a huge amount of the traditional AR skill floor disappears. You still need to understand coordinate spaces, anchor drift, and lighting estimation if you want something that doesn't look obviously fake - but you don't need six months of computer vision coursework to place a rotatable model on a desk. A workable zero-budget path in If someone wanted to start from nothing, the sequence that actually gets you to a working demo fastest looks roughly like this: - Basic web fundamentals - HTML/CSS/JS. Nothing AR-specific yet. - Blender, focused narrowly on: primitive modeling, UV unwrapping enough to apply a texture, and glTF export settings. Skip sculpting and rigging until you need them - most first projects don't. - WebXR + Three.js, specifically the immersive-ar session type, hit-test API for surface detection, and anchors for keeping content spatially locked. This is where most of the actual learning curve lives - session lifecycle management and reference space types (local ,local-floor ,bounded-floor ) trip up almost everyone at first. - Distribution via the web, which sidesteps app store review, code signing, and platform-specific builds entirely for a first project. Where AI assistants genuinely help here isn't in replacing the engineering - it's in compressing the time between "I don't understand what a reference space is" and "I have a working example to modify." WebXR documentation is sparse and inconsistent across browser implementations; having something to interrogate about a specific error or a specific spec inconsistency removes a lot of dead time that used to just be StackOverflow archaeology. Scope the first project correctly Don't start with a multi-user persistent world. Start with something you can describe in one sentence and implement in an afternoon: place the solar system on a desk. GLB model (Blender export) ↓ Three.js scene graph ↓ WebXR hit-test → surface detected ↓ Anchor created at hit-test result ↓ Model attached to anchor ↓ Rendered via ARCore pose tracking ↓ Visible through phone camera, spatially locked Once that pipeline works end to end, the next questions are the ones that actually matter: Does the object respond to touch input? Does it carry queryable data (tap a planet, get orbital parameters)? Does it need to persist across sessions (cloud anchors), or is per-session tracking enough? Can more than one device see the same anchor at once? Those are real engineering problems, and they're much easier to reason about once the base pipeline isn't the bottleneck. Where this is actually going The metaverse's collapse removed the pressure to make every AR demo look like a platform launch. That's arguably better for the technology, not worse - it means the interesting work is happening in contexts that don't produce keynote moments: anatomy visualization, geological cross-sections, molecular modeling, museum object reconstruction, engineering prototypes viewed at scale before fabrication. None of that requires convincing anyone to wear a headset eight hours a day. It requires a tracking pipeline accurate enough to be useful, a distribution model light enough that a student opens a link instead of installing an app, and content pipelines cheap enough that a single developer with Blender and a phone can ship something real. That's a smaller claim than "the next computing platform." It's also one that's already true. Top comments (0)