How does a real-time 3D walkthrough in a browser work, and what should architects know?

What a real-time 3D walkthrough in a browser actually is

In real-time visualisation, the image is not a recording. The visitor's device draws it on the fly, with every movement of the mouse or finger. That is why visitors can walk wherever they like and are not tied to a predefined route.

Unity is a development environment that can export a scene to WebGL. The program is compiled to WebAssembly and runs inside the browser, with no plug-ins and no installation. It uses the graphics card through a standard browser interface supported by all major browsers.

For an architect, the key point is that this is still a game engine. Everything the visitor sees must be calculated by the device within a fraction of a second, however well the model looks in the design tool. We have covered the difference between such a walkthrough and a panorama separately, so here we focus on the technical background.

Real-time 3D walkthrough in a browser: what happens when the link opens

The browser first downloads the launch page, then the main files: the WebAssembly code, the scene data and any external assets. The files are usually compressed, so the server and network must deliver the compressed content correctly. On a first visit, this is the longest part of the wait.

Next come unpacking, engine start-up, shader compilation and loading the scene into memory. On a repeat visit the browser may take some files from its cache, but that depends on server and device settings. While waiting, visitors need to see progress, otherwise many will leave.

Larger projects are best split into parts. The base space loads first, while additional floors or content load only when needed, which Unity supports through loadable content bundles.

• Download: code, scene data and textures
• Preparation: unpacking, engine start-up, shader compilation
• First frame: scene in memory, controls ready
• Streaming: additional content loads afterwards

WebGL architecture visualisation: preparing the model

A model from a BIM tool or modeller is not ready for the browser. It contains a great deal of detail the visitor will never see, and too much data for an average device. The transfer process from Revit or ArchiCAD is described in a separate article, so here we cover the principles of optimisation.

The aim is to reduce the amount of data the device must process in a single frame, as well as the memory footprint. The biggest gains come from geometry, textures and lighting.

Pre-calculated lighting gives an attractive look at low cost, but it does not light changes to the scene on the fly. The trade-off between appearance and speed is therefore a project decision, not a technical formality.

• Geometry: remove hidden surfaces and invisible detail, use levels of detail (LOD)
• Textures: compressed formats, sensible resolutions, packing into atlases
• Lighting: baked lightmaps instead of many dynamic lights
• Rendering: batching, instancing and occlusion culling
• Materials: as few different materials and shaders as possible

Devices and browsers: what to plan for

Modern desktop computers with strong graphics rarely cause problems. Integrated graphics in business laptops are noticeably weaker, while phones and tablets are limited by memory, heat and battery. We therefore plan the project for the weakest device the target audience really uses.

Controls differ too. On a computer there are a keyboard and mouse; on a touchscreen there is a virtual joystick or a tap on the destination in the space. On phones, a browser short of memory may even close the page, so offering a lighter quality setting is often sensible.

Testing on real devices is essential. A simulation on the developer's machine does not show how an older phone will cope, so check at least Chrome, Safari, Edge and Firefox.

Real-time visualisation: where the limits lie

WebGL runs inside the browser's security sandbox, so the engine has less freedom than a desktop application. Memory is limited, multithreading in Unity for the web is heavily restricted, and there is no direct access to the file system.

The look cannot match pre-rendered images. Reflections, soft shadows and complex glass call for compromises, so a real-time walkthrough is not a substitute for photorealistic renders but a complement with a different purpose.

External factors add further limits: corporate networks, embedding in a page through a frame that restricts fullscreen mode and mouse capture, and a visitor's slow connection. The newer WebGPU standard is evolving, but support still varies between browsers and devices, so do not build mandatory assumptions on it.

Common mistakes when publishing a 3D walkthrough

The most common mistake is publishing the model in the form it left the design tool. The result is long loading times and stuttering on average devices.

Before publishing, open the link in a clean browser with no cache, on a slower connection and on a phone. If the experience still makes sense, the project is close to ready.

• Testing only on a powerful computer
• Unlimited texture resolution and too many different materials
• No loading progress indicator
• Server without compression or with incorrect header settings
• Touch controls and mobile view overlooked
• No fallback content when the browser does not support WebGL

What you can do next

Open the public demo, a free 3D walkthrough of a sample house, on several devices and note the loading time, the response of the controls and the look of the shadows. ARHIX builds such walkthroughs in Unity WebGL, so the demo is a useful reference for a conversation about your project. Notes from these tests make a good basis for the next step.

Then draw up a list of target devices, set an upper limit for data size and agree what must be shown precisely in the space and what can be simplified. That way you avoid problems that would otherwise only appear just before launch.