Immersive Walkthroughs: Clients Explore Your Scheme, No Install.
Immersive Walkthroughs turns a GLB export into a first-person walk a client opens with a link. No plugins, no render farm, no software to explain.
What Immersive Walkthroughs actually does
Immersive Walkthroughs takes a GLB export straight from SketchUp or Revit and turns it into something a client can walk through in a browser tab. No install, no plugin, no VPN link to arrange before a site meeting. You drop the file in, the mesh gets optimised automatically so it doesn't choke a laptop with an integrated graphics card, and you land inside the scheme at eye level, walking with collision rather than floating past it on a fixed camera path.
That distinction matters more than it sounds. A fly-through camera can pass through a wall, hover above a stair, or glide through a door frame that wouldn't actually open. A first-person walk with collision behaves like a person would: it stops at the wall, it has to find the door, it has to climb the stair. That's a much closer proxy for how the building will actually be experienced.
Building the walkthrough is desktop-only, since you need the horsepower to process the GLB and set it up properly. But the result is not desktop-only. It plays anywhere: a client's laptop, a planning officer's shared meeting-room screen, a tablet at a public exhibition stand. This lives in Studios at /game-studio, renamed from Game Studio and now focused purely on this one job: the walkthrough template, done well, rather than a general-purpose game builder trying to be everything.
A first-person walk with collision tells you things a rendered camera path never will: whether a corridor actually reads as generous, whether a door swing clashes with a run of stairs, whether a threshold feels cramped in practice rather than on paper.
Why a browser link beats a rendered flythrough for client meetings
A rendered video, however well composed, shows one path through a scheme: the path you chose. It's a good path. You've picked the hero views, timed the reveal of the double-height space, lingered on the kitchen island. But it's still your narrative, not the client's exploration. A walkthrough hands the camera over. The client turns down the corridor you didn't plan to show them. They stop in the hallway and look back at the front door to check the sightline. They open the wardrobe alcove you thought was a footnote and it turns out to be the thing they care about most.
That shift, from directed narrative to active exploration, surfaces a different category of question. Ask someone to comment on a video and you get feedback on composition and mood. Watch someone walk their own path and you find out what they actually notice, which is not always what you expected them to notice.
There's also the practical matter of access. Enscape, Twinmotion and Unreal-based viewers are excellent at what they do, but they're built for the architect's desktop, not the client's laptop. Nobody is installing a real-time renderer licence to sit through one design review. A committee member on a shared council laptop, a client dialling in from a hotel business centre, a stakeholder joining from their phone between meetings: none of them can be expected to install anything. A /play link just opens. That's the entire pitch.
Worth being clear about what this isn't. It's not a substitute for a desktop GPU renderer like Lumion or Twinmotion when you need a polished cinematic still or a hero flythrough for a competition board. Those tools are optimised for visual fidelity and a controlled narrative, and they're very good at it. Immersive Walkthroughs is optimised for something else entirely: access. It solves the problem of getting a client inside the building, not the problem of making the single best-looking frame of it.
The point isn't rendering quality. It's that the client installs nothing, arranges nothing, and waits for nothing before they're standing inside the scheme.
Getting a model from CAD to walkthrough-ready
The workflow starts in your existing tools. Export a clean GLB from SketchUp or Revit, and purge unused geometry and materials before you do. A model that's accumulated three years of superseded furniture blocks and orphaned material libraries will export bigger and slower than it needs to, and none of that clutter helps the walkthrough. Clean geometry in, clean walkthrough out.
Bring the GLB into Immersive Walkthroughs and let the automatic mesh optimisation do the heavy lifting from there. This is the step that keeps the experience running smoothly in a browser rather than stuttering on a client's five-year-old work laptop, and it happens without you needing to manually decimate polygons or bake down textures by hand.
Before you send anything to a client, check two things. First, scale and eye-level placement. The convention for a first-person architectural walkthrough puts the eye at roughly 1,750 to 1,800mm, which reads as a natural adult standing height and keeps proportions honest. If the starting position is off, either buried a little in the floor or floating above it, that's the first thing a client notices, and it undermines confidence in everything that follows before they've even looked at the design.
Second, test collision at pinch points: staircases, tight corridors, doorways, anywhere two surfaces meet closely. These are exactly the places most likely to reveal a modelling gap, a missing face, a stair that clips through a soffit, a door that doesn't actually align with its frame. Better to find that in your own test walk than have a planning officer find it live.
Two ways to share, and when to use each
Once the walkthrough is built, there are two ways to get it in front of someone, and the choice comes down to where they'll be standing when they open it.
The /play link is the default for anything with reliable browser access: an email to a client ahead of a review, a link dropped into a planning officer's inbox alongside the application documents, a stakeholder session over video call where you share the URL in the chat. It's the fastest option to set up and the easiest for someone else to open cold, with no prior arrangement needed.
The standalone offline export covers the situations where you can't guarantee a connection: a site cabin on a rural project with patchy signal, a public exhibition stand where you don't want to depend on venue Wi-Fi holding up through a busy afternoon, a community consultation event in a hall with no broadband at all. You load the offline package onto a laptop or tablet in advance and it runs regardless of what the internet is doing that day.
| Scenario | Recommended format | Why |
|---|---|---|
| Client review over video call | /play link | Fastest to set up, opens in any browser mid-meeting |
| Planning committee submission | /play link | Officers open it cold, no install or file transfer required |
| Public exhibition stand | Offline export | No dependency on venue Wi-Fi |
| Rural site cabin meeting | Offline export | Works with no signal |
Either version comes from the same GLB import, so there's no duplicated modelling work to get both. Build the walkthrough once, then choose the delivery format that matches the room you'll be standing in.
One GLB import produces both formats. The decision between /play link and offline export is about the venue, not the model.
Where a walkthrough fits alongside the rest of your presentation
A walkthrough is a companion to your Design and Access Statement, not a replacement for it. The document does the job of justification: policy compliance, design rationale, the reasoning a planning officer needs on record. The walkthrough does a different job entirely. It answers "what does it feel like to be inside this", which no amount of well-argued text can fully substitute for.
Pair the two deliberately. Send the walkthrough link alongside stills built in Scene Composer or a rendered flythrough for the moments in the scheme that benefit from a fixed, considered shot, a carefully framed view of the entrance sequence, the light quality in a top-lit stair core at a particular time of day. Those authored images still matter. They're how you control the first impression and make the case for the parts of the design you most want noticed. The walkthrough is what you hand over once that first impression has landed, so the client or committee can go and check it for themselves.
For competition entries, this pairing works well on a physical board too. A QR code linking to the /play version gives jurors a way to explore past what fits within the panel's fixed frame, without you needing to squeeze every view onto the sheet. The board makes the argument; the linked walkthrough lets a juror who wants more go and find it.
It's also worth building into how you run client reviews generally. Feedback gathered from watching someone walk their own path through a scheme tends to surface different concerns to feedback gathered on a rendered video. People stop where they're actually uncertain, not where you told them to look. That's a genuinely useful signal, and it's one you only get if you hand over the controls.
A rendered still tells the client what to look at. A walkthrough tells you what the client actually looked at. Use both, deliberately, rather than treating one as an upgrade of the other.
Takeaway: Immersive Walkthroughs isn't trying to out-render Lumion or Twinmotion, and it doesn't need to. It solves the access problem: getting a client, a committee member or a juror standing inside your scheme without asking them to install anything first. Export a clean GLB, let the mesh optimise, check your eye level and collision, then choose a /play link for the meeting or an offline export for the venue with no signal. Either way, the model does the talking, and the client gets to choose where they walk.
Try ArchAdemia Tools for yourself
Draw it, model it, render it, publish it. One place, built for architects and small practices. Plans from £29 a month, all in.