Real-Time 3D in the Browser: How We Shipped a Whole Town

Short answer: yes, it works. Modern browsers draw 3D through WebGL without a plugin. We put a medieval town of 55 buildings, 27 characters and 1.76 million triangles onto a web page. As the visitor scrolls, the camera walks the streets and orbits the characters and the dragon. It is not a video: every frame is drawn on the visitor's device as it happens. Here is how it was built, what we measured, and where we got it wrong first.

1. A raw scene never goes straight to the web

The scene was built in Blender and the first web export weighed 494.3 MB. That is unusable on a web page. Three steps brought it down:

• Textures dropped to 1024 pixels. The camera never gets close enough to any surface to resolve 4K detail; the rest was pure download time.
• Textures converted to WebP. Same visual quality, considerably smaller files.
• Geometry compressed with Draco. Triangle data travels compressed and is decoded in the browser.

Result: 54.7 MB, roughly one ninth of the original, with no quality loss visible in frame.

2. Do not draw the camera path by hand

In the first build we placed the camera path with ten control points. It looked fine. Then we measured it:

• The curve passed through five separate buildings; about 14% of the tour was inside a wall.
• 38.8% of the path sat within 3 metres of a wall.
• The final leg ran at 5.3 times the median speed, so the camera lurched when it got there.

Opening it in a browser confirmed the numbers: the narration card read "Angel Statue" while the camera stood in the dark interior of a house.

The second build computes the route. We derive a clearance field from the scene's 165 collision boxes and run A* to find a path through the streets. The generator refuses to write the file if a single sample lands inside a building. The current route is 799 metres, 25 stops, 6,057 samples and zero wall contacts.

3. Solve pacing in the data, not in the browser

Camera speed had to stay consistent. The usual approach is to compute arc length in the browser and normalise speed from it, which is both fiddly and paid for on every frame. We baked the pacing into the data instead: the path is generated as 6,057 samples spaced evenly in time. The distance between two samples is the speed, and pausing at a stop simply means many samples in the same place. The browser just walks the array. No speed jumps, no extra maths.

4. Bring the scene to life, but know the price

A static 3D scene starts to look like a model kit very quickly. We added the following, all at runtime, with no re-export:

• 48 animation clips already sitting inside the file were discovered; four figures now play their own.
• The spine and neck bones of the crowd received a sway of well under a degree. They no longer stand like statues, and the per-frame cost is too small to measure.
• The magic circle rotates, the fireball flickers irregularly, and lightning strikes on an interval.

What we deliberately skipped: real depth of field. It requires drawing the scene a second time and doubles the draw calls. A vignette and a slight lens separation give the same cinematic feel for close to nothing.

5. So who is this actually for?

Real-time 3D does not belong on every site. It earns its place where the product itself does the selling:

• Vehicle, machinery and equipment showrooms — turning and zooming the product moves the visitor toward a decision.
• Furniture, architecture and interior presentations — material and scale read better than in a photograph.
• Property and development launches — a building that does not exist yet becomes walkable.
• Tourism and hotel experiences — seeing a place beats describing it.
• Brand-led landing pages — the fastest way to look unlike the competition.

By contrast, putting 3D on an accounting dashboard, a news site or a speed-critical product listing gives the visitor waiting time rather than value. We apply the rule to ourselves: this scene is not embedded in our home page. The home page carries a poster and a link, and the scene loads on its own page.

6. Honest limits

What misleads most in work like this is showing only the good side. Our scene has open items too. The triangle budget landed at 1.76 million against a 1.5 million target, because the cathedral was exempted from simplification. Texture atlasing was not done. Four crowd figures arrived from the source files in a T-pose; rather than rebuild the scene we detected them by measurement and hid them. All of it is fixable, but that is where things stand today.

Related: Web & Digital Solutions · Web Studio (live 3D) · Türkçe sürüm

Every figure in this article was measured on our own project (July 2026). File sizes, triangle counts and route length come straight from the build scripts' output.