3D Website from a Revit Model: a Web Development Case Study

Apartments are usually sold off pictures, floor plans and renders. The buyer has to imagine where the flat sits in the building, which way the windows face and how the rooms connect. In this web development case study we show how we turned an architect's Revit model into a 3D website where visitors turn the house themselves, cut it open at floor height and look at each apartment on its own.

This is a demo. The site is called 3D House Demo. It isn't a client commission and no real apartments are sold through it. We built it to show what's possible in the browser with an architect's own files. Everything described below works, and you can try it yourself.

At a glance

• Source file: the FBX export of an architect's Revit model, 24 MB.
• On the web: a Draco-compressed glTF file, 2.2 MB. Same geometry, roughly eleven times smaller.
• The house: five apartments over two floors. The model has 347 meshes and 589,419 vertices.
• What visitors do: turn the house, switch views (aerial, street, plan), pick a finish (Render, White, Lines), explode the floors apart and choose an apartment.
• Tech: Next.js, React Three Fiber and three.js, in a single WebGL canvas. Nothing is pre-rendered.

Who a 3D website like this is for

We built the demo with real-estate developers and architects in mind: people who market or present apartments before the building is finished.

The usual approach is rendered images and PDF plans. They look good, but they're static. Every new angle is a new render, and buyers only see what someone chose to show them. On a 3D website the visitor picks the view. They see where an apartment sits relative to the others, which floor it's on, and what the building actually looks like from every side.

Crucially, nothing new has to be modelled. The architect already has the model in Revit. The question is how to get it onto the web quickly and correctly.

From Revit to the browser: 24 MB down to 2.2 MB

Revit can export FBX. That works for passing files around, but 24 MB is too much for a web page, especially on a phone with mobile data.

So we convert the file with a separate script before publishing:

1. three.js's FBX loader reads the FBX file.
2. All materials are replaced with one plain material, since the browser assigns them again anyway (more on that below).
3. three.js's glTF exporter writes the model out as a GLB file.
4. gltf-pipeline compresses the geometry with Draco.

The result is a 2.2 MB file. The geometry is the same; it's just written down far more compactly. The browser downloads it once, decompresses it, and everything after that happens on the visitor's device. While it loads, the visitor sees a progress bar, so it's clear something is happening.

Revit uses Z as up; the 3D web world uses Y. The model is rotated on load and centred so it stands on the ground.

Materials from Revit element names

A Revit export gives every surface the same grey material. Put that on the web as is and it looks like a plaster model.

We didn't paint new textures. Instead, the code reads each Revit element's name and assigns a material from it. The architect's model uses Estonian element names, so for example:

• klaas (glass) becomes transparent glazing;
• välissein (exterior wall) gets a rendered façade tone;
• põrand (floor) and vahelagi (intermediate slab) become oak floors;
• railing becomes a steel railing;
• timber gets a timber column tone.

There are 11 material groups in all, from glazing and aluminium frames to furniture and fit-out. Each gets a physically based (PBR) material: colour, roughness and metalness. When the architect changes the model and sends a new export, new elements pick up their material from their name automatically.

A realistic render in real time

The model is rendered live in the browser with WebGL. To keep it from looking like a generic 3D viewer, we used a few techniques:

• sunlight and shadows from a single directional light, with ambient light from an environment map;
• ambient occlusion, which darkens corners and joints the way real light does;
• neutral tone mapping, so white surfaces don't blow out;
• a shadow-only ground whose tone is calibrated to the page background, so the house stands on the page rather than in a box.

For that last one, we sampled the rendered pixel colour with Playwright and tuned the backdrop until it matched the page background exactly.

Besides the realistic render there are two more finishes:

• White, a white massing model with light, subtle edges;
• Lines, where surfaces are white and edges dark, like an architect's drawing.

So the same model works both for a buyer who wants to see what the house looks like and for an architect who wants to see its form.

Section cuts and apartments

The heart of the demo is picking an apartment. When a visitor chooses one, three things happen:

1. the model is cut horizontally at that floor's height;
2. everything outside the apartment's footprint is hidden, so the apartment is lifted out of the building;
3. the camera flies over and frames the apartment beside the rest of the interface.

Each apartment has three views: overview, plan from above, and reverse angle.

We didn't pick the cut height by hand. The code finds the floor, intermediate slab and roof slabs in the model and reads their heights. The cut sits at 62% of each storey, floor to ceiling: high enough to read the rooms, low enough to see in. The apartment boundaries come from the architect's floor plans, the same plans shown on the page next to the apartment list.

The cut uses clipping planes rather than slicing the geometry. That means the cut can move smoothly and the model stays intact. Where the cut opens a wall or slab, its inside is filled solid dark, as in an architectural section drawing. That only happens while a cut is active; otherwise the hairline gaps between curved wall segments would show up as dark dashes.

Explode, views and the compass

Beyond the apartments, the page has a few more controls:

• Explode lifts the upper floor and roof with a slider so you can see into each level. The layers are split by the same slab heights.
• Aerial, Street and Plan are preset camera shots. The plan view uses a very narrow field of view from far away, so it reads almost like a flat drawing.
• The compass shows the building's footprint and which direction the camera is looking from. Drag it to walk around the house; it also works with the arrow keys.

We deliberately left out zoom and pan, and the camera can't go below the ground. Visitors can't get lost, and the house always stays in frame.

What got difficult

As with any project, some problems only showed up with the real model:

• Flickering surfaces. A Revit model has many faces that sit in exactly the same plane, such as the entrance canopy and wall joints. At first the camera's near and far planes were too far apart, there wasn't enough depth precision, and those faces flickered as the model turned. The fix was to keep those planes tight around the model at all times.
• Touch on phones. When the 3D canvas fills the screen, a swipe wants to scroll the page and turn the model at the same time. The fix: a vertical swipe scrolls the page, a horizontal one turns the house.

Speed and phones

A 3D website is heavier than a regular site, and there's no point pretending otherwise. A few decisions keep it reasonable:

• the model loads once and the whole page shares one WebGL canvas;
• the shadow map is only recalculated when geometry moves, because the sun doesn't;
• when the 3D section is scrolled off screen, rendering pauses;
• on phones, pixel density is capped and ambient occlusion runs at half resolution.

For speed and Core Web Vitals in general, see our article on custom websites versus templates.

What a project like this needs from a developer or architect

If you're considering a similar 3D website, here's what needs agreeing up front:

• Model: a Revit, FBX or glTF export. The cleaner the element names, the easier the materials.
• Apartment plans: apartment boundaries and data (area, rooms, balcony).
• What visitors should do: just look, or also choose an apartment, reserve, send an enquiry?
• Data: does apartment status (available, reserved, sold) come from manual edits or from a system?
• Brand: the site designed around the developer or the project.
• Changes: what happens when the architect updates the model?

In the demo there's no system behind apartment status or enquiries. In a real project we'd connect it to the developer's sales or CRM system.

Summary

The architect's Revit model already exists, and it's more accurate than any render. Good web development gets it into the browser so it loads quickly, looks like a real building, and lets buyers find their apartment themselves. Our 3D House Demo shows that a 24 MB FBX fits into 2.2 MB and runs on a phone.

Try the demo at ravien-3d-house-demo.vercel.app, and see our other projects in our work. If you're selling or planning apartments and already have a Revit model, get in touch. We'll look at whether a 3D website is the right fit for your project.