Lessons from a browser 3D walkthrough: a rebuildable Blender model, baked lighting, streamed assets, performance checks, and a guide using plan sources.
We recently built a walkthrough of a building that doesn’t exist yet: a site of about 23,000 m² with an auditorium, a teaching hall, a lobby, and hundreds of parking spaces. The goal sounded simple. Anyone with the link should be able to walk it at eye level, at any hour of the day, on the phone in their pocket, and ask questions about it out loud.
Each part of that sentence turned out to be an engineering decision. A browser link removed the need for an installed app. We also chose local browser rendering to avoid a GPU-streaming service. “At eye level” meant the model had to hold up at close range, not just from a flattering aerial angle. Adjustable time of day required lighting that could change in the browser. “On a phone” put a hard ceiling on everything.
This note is about the decisions that mattered, and the ones we would make again on the next project.
An original diagram of the pipeline from plans to a browser walkthrough.
One model, and it has to be rebuildable
Make the Blender file the single source of truth
Plans change. A door moves, a finish is swapped, a room is renamed. If the web version and the 3D model drift apart, every change becomes a reconciliation project. We learned this the hard way: at one point, merging a web-side model back into Blender touched hundreds of objects.
The fix was a rule: the Blender master is the only source of truth, and every change to it is a script. The master can be rebuilt from its geometry at any time, and the web build is always derived from it, never edited on its own. When the architect sends a revision, we change the master and rebuild everything downstream.
Generate what the plans already specify
A lot of the model is already written down. The finish schedule lists materials room by room, so the texture sets are generated from it rather than hand-picked. The surrounding neighborhood comes from open building footprints and street data, massed simply so windows look out at the real context without pretending to be a model of it. Generating these parts keeps them consistent and makes the next revision cheap.
Light is baked, then remixed
One bake, every hour of the day
Full real-time global illumination did not fit our target device budget. Pre-rendered lighting usually means one time of day, frozen. We wanted both: believable light and a slider from 6:00 to 22:00.
The answer was to bake light into separate channels instead of one final image. Each part of the site gets lightmaps with the sky, the sun at different angles, the interior fixtures, and the site lights stored apart. In the browser, a shader mixes those channels for the chosen hour, with sun positions computed from the real site location and date. When evening comes, the interior fixtures and site lights fade in. One bake covers the whole day.
Put heavy work on rented GPUs
Baking a site this size is slow on a laptop. The bakes run as parallel jobs on cloud GPUs, split so each job handles part of the site, with the same scripts able to fall back to a local machine. That changed how often we could afford to rebake, which changed how willing we were to accept a late plan revision.
Set a browser performance budget
Stream the site in cells
A single download of the whole site would take too long and use too much memory. The model is cut into 30 m cells, each with its own geometry and lightmaps. Geometry is compressed with meshopt and textures ship as KTX2, which stays compressed on the GPU. The cells nearest the visitor load first, and the rest arrive while they walk.
The first view gets extra care. Its shaders are compiled before the loading screen ends, so the first steps don’t stutter while the GPU catches up. First impressions of a walkthrough are formed in the first ten seconds.
Make the build fail when it gets too heavy
Performance work tends to happen at the end, under deadline pressure. We made it a property of the pipeline instead. The build has hard budgets for download size, draw calls, and triangle counts, and it fails when a change exceeds one. A chair model that was twice as detailed as it needed to be got caught by the budget, not by a slow phone in a client meeting.
Visual regression tests work the same way. Named views are captured on every build, and a view that changes more than expected fails the check. That lets us optimize aggressively while checking that important visual details remain.
Measure on the devices people use
Frame rates on a development laptop say little about a mid-range phone. We test at phone sizes and on real devices, and we are honest in our own notes about which builds are ready to show. The browser adapts detail per device, but adaptation only helps if the baseline is already within budget.
Walking needs to feel physical
Collision, navigation, and a way to get lost less
People expect to walk into a building, not float through it. The walkthrough uses a capsule character with collision against the model, and a navigation mesh so the guide can walk a visitor from where they stand to where they want to go.
Large sites are disorienting at eye level, so wayfinding matters as much as rendering. Named places are searchable, a minimap shows where you are, and picking a place walks you there. Small touches, like footsteps and ambient sound, did more for the sense of space than another round of texture detail.
A guide that answers from the plans
Separate the voice from the facts
The walkthrough has a spoken guide. Visitors ask questions, and it answers. We separated the conversation from the tools that retrieve project facts.
A real-time voice model runs the conversation. When a question needs a fact, it hands off to an agent with tools to search and read the plan notes. The answer comes back with the sheet it came from, and a label saying whether the figure is printed on the plans, calculated from them, or estimated from the model. When the plans don’t say, the guide says so.
That labeling turned out to matter to people reviewing the building. A parking area estimated from the model is a different claim from a figure printed on a sheet, and treating them the same would have eroded trust quickly. Plans also disagree with each other sometimes, and a guide that surfaces the disagreement is more useful than one that picks a number.
Cap the session, not just the tokens
Voice sessions have a way of running long. Sessions have limits on length and cost, set on the server. Recording and retention need their own explicit settings. Those limits are cheap to add at the start and awkward to retrofit.
What we would do again
The short list
If we started the next project tomorrow, these would stay:
- A scripted master model that can be rebuilt from scratch, with the web build always derived from it.
- Lighting baked into channels and remixed in the browser, to support time changes without full real-time light simulation.
- Streaming by cell, with the first view precompiled.
- Budgets and visual tests that fail the build, from the first week.
- A voice layer that delegates every fact to tools reading the source documents, and labels how each figure was obtained.
This project became the base of our pre-construction 3D walkthroughs, with a fixed price for each project. See the SASD case study for the delivered implementation.
These are decisions from this implementation. Device tests still determine which level of detail is suitable, and plan revisions still need review before publication.