Furniture is expensive and physical — people want to see it. The buyer wants to know how the back of the sofa sits, what the fabric really looks like, and whether the module fits their living room. A flat product photo answers none of those three properly. This article walks through the structure of a 3D visualization setup we built for a furniture collection, including what works and what isn't connected yet.
What Was It Built to Solve?
The goal was simple: when a visitor opens a product from the collection, they should be able to inspect it as completely as possible without driving to the showroom. That means three things — seeing the product from different angles, reading module dimensions clearly, and comparing fabric and colour options. All three are the questions asked most often before purchase, and therefore the questions a sales team answers over and over every day.
Catalogue Structure: Two Pages, One Data Source
The system is only two pages: a home page listing the collection, and a single product detail page shared by every product. There is no separate HTML file per product; the detail page builds its own content based on the product key in the address.
What makes that possible is that the product data is entirely separated from the interface. All products sit in a single data source, each one a record with the same fields:
| Field | Purpose |
|---|---|
title | Product name — used in the heading and the catalogue card |
cat | Category — for filtering and the card label |
key | Image folder name — gallery paths are derived from it |
files | List of product images — gallery and thumbnails |
rows | Dimensions table rows — module, width, depth, height |
The critical piece here is rows. In furniture, dimensions aren't decoration; they are part of the purchase decision. If a corner unit has separate measurements for its right-arm module, its middle module and its recliner, those belong in structured rows rather than free text. The same data can then be rendered as a table on the page and later handed to a quote form or a product automation in exactly the same shape.
Gallery: Full-Size and Thumbnail
Each product folder keeps two versions of every image: the full-size one and a smaller one in a thumb subfolder. The catalogue page and the gallery strip only load the small versions; the full-size image comes in only when the visitor moves to that frame.
Without that split, a product page with twelve images makes the visitor download eleven images they never look at. On a mobile connection that is a direct cost to how fast the page opens. In an image-heavy catalogue, most of the performance comes not from clever optimization but from simple separations like this one.
Where Does the 3D Viewer Attach?
Here we should be straightforward: in this system 3D viewing is not an engine embedded directly in the page. The product page has a "View in 3D" button; the button opens a modal, and inside that modal sits an empty container where the viewer will live. The attachment point and the function called on open are defined in advance; the 3D engine itself is not yet connected at this stage.
Product page
↓
[View in 3D] button
↓
Modal opens (product name + close)
↓
Empty mount container → engine goes here
↓
Open hook is called (product object + container)Why build it this way? Because the catalogue and the viewing engine are two independent decisions. The engine choice can change over time — from a WebGL model viewer to a photo-sequence 360° solution, or the other way round. When the attachment point stays fixed, that switch touches one place only; the catalogue, gallery and dimensions code stay exactly as they are.
The second benefit is performance: the viewer loads when the visitor presses the button, not when the page opens. The 3D feature therefore costs nothing in speed for visitors who never use it.
Real 3D Model, or 360° Photo Sequence?
In practice there are two routes, and both get marketed as "3D viewing" — but they are technically different things:
- A real 3D model (GLB/GLTF) — The geometry is rendered live in the browser. Free angles, zoom and material switching all become possible. In exchange you pay for modelling each product and carry heavier files.
- A 360° photo sequence — Photographs taken at fixed angle intervals are shown in order. As the user drags, the frame changes and rotation is implied. No modelling needed, and because these are real product photos the texture is exactly right; but free angles and zoom are limited.
Here's what's interesting in furniture: the realism of the fabric often matters more than free-angle rotation. A well-shot photo sequence can be more convincing than a mediocre 3D model. It's a choice to be made alongside product count and budget — you can't simply declare that "a 3D model is always better".
What Changes as the Catalogue Grows?
For a five-product collection, keeping product data in a single file is entirely reasonable. At fifty products with regular price and stock changes, that same structure becomes a maintenance burden. At that point the data source moves to a spreadsheet or a database and updates get handed to automation — the structure described in our article on product and stock automation with n8n does exactly this job.
What matters is that this migration doesn't touch the interface. Because the product data was kept apart from the front end from the start, changing the source doesn't require rewriting the catalogue. That is the practical payoff of building something small that can grow.
Five Things to Get Right
- Separate the data from the interface. Product name, dimensions and image list belong in one source; the page should render from it.
- Keep dimensions structured. Rows and columns rather than free text — you'll need that shape later for quotes and automation.
- Prepare images at two sizes. Small for listing, full-size only for the frame actually being viewed.
- Leave the engine attachable. A fixed mount point reduces an engine change to a single-file job.
- Keep the path forward open. A visitor inspecting the product should be able to request a quote from the same screen; the viewer shouldn't be a dead end.
If there are items in your range where 3D visualization would genuinely earn its place, we can work out together which product to start with and how to build it — see our 3D product visualization page. For everything else we build, take a look at our AI automation services.