Let Clients Drive: Building a Browser 3D Review Room That Closes Deals

I spent the better part of a decade sending clients MP4 turntables. They looked great, they compressed badly, and they answered exactly one question: what does this look like spinning? They never answered the questions clients actually ask, which are things like how thick is that edge, what happens if we swap the finish, and can I see it next to the packaging.

A proof room fixes that. Not a full configurator, not a game — just a link that opens a real-time scene in the browser, lets a client orbit, click, and comment, and makes your work feel like a product instead of a render.

What a proof room is, precisely

A proof room is a single-purpose web page containing one interactive scene, a handful of annotations, a finish or variant switcher, a licensing note, and a way for the client to leave feedback tied to the geometry they're looking at. It lives at a private URL. It loads in under a few seconds on hotel Wi-Fi. That's the whole brief.

The reason it wins work is psychological, not technical. A client who can rotate the object feels ownership before they've signed anything. That feeling is hard to get from a PDF.

Pick your stack without overthinking it

You've got three realistic options.

Model Viewer or similar drop-in components. Fastest path. Load a glTF, get orbit controls, AR on mobile, and hotspot support with almost no code. If your scene is one asset on a neutral backdrop, stop here and ship it.

Three.js or Babylon.js. The right call once you need annotations with custom logic, multiple variants, section views, or measurement overlays. Both are mature, both handle glTF well, and both have enough community examples that you're never stuck for long.

Raw WebGPU. Tempting, and genuinely impressive for heavy scenes with lots of instances or complex materials. But WebGPU support still isn't universal enough in 2026 that I'd make it the only path for a client deliverable. Build on WebGL, and treat WebGPU as a progressive enhancement you enable behind a capability check for clients on modern hardware.

For the example below I used Three.js, mostly because the annotation system I wanted was fifteen lines of raycasting code.

Set a performance budget before you model

The single biggest reason browser 3D review pages fail is that artists export the same asset they'd send to a render farm. Don't.

My working budget for a client proof room:

• Initial download under 4 MB, compressed, including the environment map
• 60 fps on a three-year-old laptop with integrated graphics
• Under 150 draw calls, ideally under 60
• Texture atlases at 2048px max for hero surfaces, 1024 for everything else
• Time to first frame under 3 seconds on a normal home connection

To hit those numbers, run your glTF through Draco or meshopt compression, convert textures to KTX2 with Basis, merge static meshes, and bake lighting into an environment map rather than shipping a stack of punctual lights. A clean product asset that started at 40 MB usually lands around 2.5 MB after that pass, and — this is the part clients notice — it looks identical.

The example: a modular desk lamp

Let's make it concrete. A lighting brand in Portland asked for review of a modular task lamp — three arm lengths, four finishes, one optional diffuser. Classic case where a turntable fails, because the client's real question is which combination to put in the catalog.

Step one: prep the asset. Export the lamp as a single glTF with each finish-swappable part as a separate named node. Bake the base and shade materials to a shared atlas. Keep the diffuse, a roughness map, and a normal map — skip anything that doesn't read at review distance. Result: 2.1 MB.

Step two: build the scene. Neutral seamless backdrop, three-point-ish lighting baked into an HDRI, a soft contact shadow plane, and a subtle floor gradient. Resist the urge to art-direct this like a hero render. A proof room is a viewing environment, not a portfolio piece — the asset should carry it.

Step three: add annotations. Define anchor points in model space, then project them to screen coordinates each frame so the pins stay glued to the surface as the client orbits. Clicking a pin opens a small card explaining the decision it marks — wall thickness, cable routing, the diffuser's snap fit. Keep each note to two sentences. Clients read these. They really do.

Step four: variants. A row of swatches that swaps materials on named nodes. No reloading, no scene rebuild — just pointer the map references to preloaded textures. Four finishes is trivial; if you get past a dozen combinations, cache the loaded textures and show a spinner.

Step five: licensing panel. A collapsible drawer with three plain-language lines: what the client is allowed to do with these models, whether the scene may be shared internally, and when the review link expires. Legal language goes in a link at the bottom. Nobody reads a paragraph in a 3D viewer, but everybody reads a short list.

Step six: feedback capture. A comment button that records the current camera position along with the text, then posts to a simple endpoint. When the client writes this edge feels sharp, you reopen that exact view instead of guessing. This one feature reduced my revision rounds by roughly a third.

Step seven: deploy. Static hosting is fine — Cloudflare Pages, Vercel, Netlify, whatever you already use. Put it behind an unguessable URL and a password if the project is unannounced. Add a simple analytics event for orbit depth and annotation clicks; if nobody touches the model, you'll know within a day.

Where proof rooms go wrong

Three failure modes worth naming. First, feature creep — the moment you add a configurator with pricing logic, you're building software, not presenting work. Second, mobile neglect: a meaningful share of US clients will open the link on a phone during a commute, so test on an actual phone with actual thumbs, not a desktop emulator. Third, silent loading. A blank canvas for six seconds reads as broken. Put a poster frame and a progress bar in front of it.

Why this is worth the afternoon

Building a proof room takes maybe a day the first time and a couple of hours the second. What you get back is a deliverable that answers questions before they're asked, captures feedback in context, and makes a remote client in Chicago feel like they're standing next to you at the desk.

Turntables aren't dead. But they only spin one way, and clients want to steer.