3D Product Configurator

A configurator is three systems wearing one coat.

The first is a 3D model of your product, prepared so its parts can be addressed individually. A sofa is not one object. It is a frame, cushions, legs, piping and feet, each named, each with its own material slot.

The second is option logic: the rules describing what can change and what cannot. Oak legs are available on the three-seater but not the corner unit. The linen finish comes in nine colours; the leather comes in four and costs more. Choosing the deep seat forces the deep cushion. This is ordinary business logic and it is usually the part nobody has written down before the project starts.

The third is pricing, which is option logic with money attached, and which almost always already exists somewhere: in an ERP, a spreadsheet, a Shopify variant matrix, or a sales rep's head.

The 3D is the visible tenth of the work. The option and pricing rules are the other nine tenths, and they are where projects overrun.

A configurator is worth building when the product has genuine variety, when that variety is hard to photograph exhaustively, and when the customer's uncertainty about what they are getting is what stops the sale. Fifty product variants is a photography problem. Fifty thousand combinations is a configurator problem.

Model preparation

Almost every project starts with a file that is wrong for the web. CAD from engineering (STEP, SolidWorks, native CAD) is precise, heavy and built for manufacturing, not for a browser. It has to be retopologised to polygon meshes, given clean UVs, and re-authored with PBR materials.

The delivery format is glTF or its binary form GLB. Geometry gets compressed with Draco or Meshopt; Meshopt decodes faster, Draco usually compresses smaller. Textures get compressed to KTX2/Basis, which matters more than most people expect: a 2048×2048 texture uploaded as ordinary RGBA occupies about 16 MB of GPU memory, and about 22 MB once mipmaps exist. Six of those and a mid-range phone is out of memory. In KTX2 the same texture stays compressed on the GPU and costs roughly a quarter of that.

Getting from a 300 MB CAD assembly to a 4 MB GLB that still looks like the product is skilled, unglamorous work, and on most projects it is the single largest line item.

Option logic

Options fall into four kinds, in increasing order of cost:

• Material swaps: change colour, fabric, finish. Cheapest, since only the material changes. glTF's KHR_materials_variants extension can carry these in the file itself.
• Component swaps: show or hide parts that are all present in the model. Straightforward, at the cost of file size, since every variant ships whether or not it is shown.
• Dimensional change: resize, restretch, re-tile. Needs geometry authored for it, and materials that don't visibly stretch when it happens.
• Generative assembly: build the product from parts at runtime, as a kitchen or shelving system does. This is a modelling and rules project with a 3D viewer attached, and it is a different budget entirely.

Pricing

Price the configuration on the server, always. A configurator that computes the price in the browser is a configurator whose prices can be edited with the developer console. The browser asks; the server answers and signs the result; checkout re-validates. Every serious build does this and it is worth insisting on even when the first version is a quoting tool rather than a checkout.

Most people who email me about a configurator should buy one instead. Zakeke, Expivi, VividWorks, Simplio3D and Vectary all sell hosted configurators with e-commerce plugins, admin panels, rule builders and support, for a monthly fee that is a fraction of a custom build.

Buy the software when:

• Your products are conventional: apparel, print, furniture with a defined option list.
• Your catalogue is small enough to configure by hand in an admin panel.
• You sell through Shopify, WooCommerce or Magento and want the standard integration.
• You need it live this quarter.
• Nobody on your side wants to own a codebase afterwards.

A custom build earns its cost when:

• The assembly logic is genuinely complex: parts constraining other parts, dimensional rules, engineering validity checks that a rule-builder UI cannot express.
• The pricing lives in an ERP or a bespoke system that has to be queried live.
• The rendering is brand-critical, and "looks like a demo" is not acceptable. SaaS configurators standardise their look; that is how they scale.
• You need it embedded in an existing application rather than in a hosted iframe.
• The 3D has a second life: the same optimised model in AR, in your sales deck, in a trade show display.
• The volume is high enough that a per-order platform fee outgrows a one-off build.

If two or fewer of those apply to you, I will tell you to go and evaluate the SaaS options, and I would rather do that on a free call than four weeks into a project.

Cost tracks four things and only one of them is the 3D:

1. Model preparation: how many products, in what condition the source files arrive, and whether the product needs to be modelled from scratch. Usable CAD is a discount. Photographs and a tape measure are not.
2. Number and type of options: see the four kinds above. Ten colours is one afternoon. Ten colours across four component swaps with rules between them is a fortnight.
3. Integration depth: a standalone page you link to from an email is one project. A configurator that authenticates, reads live pricing from your ERP, writes a configured line item into your cart, and emails a spec sheet to your sales team is another.
4. Who owns the content afterwards: an admin panel where your team adds a new fabric without calling me is a real feature with a real cost. Sometimes it is the most valuable part of the build.

The things that reliably blow budgets: source files that turn out not to exist, option rules that are still being decided while the UI is built, and "can it also do X" arriving after the model is optimised. Two of those three are fixable before a line of code is written, which is why I quote from a spec rather than from a phone call.

The rhythm is consistent even when the scale isn't. Model preparation and option-rule definition run in parallel at the start; the interface is quick once both are settled; the last stretch is always device testing, because a scene that runs at 60 fps on a development machine can be unusable on a three-year-old Android.

Two scheduling notes worth planning around. First, the option rules need one person on your side who can make decisions about them: not a committee, and not "we'll confirm the finishes later". Second, budget real time for a mid-range phone. Testing only on the newest hardware is how a configurator ships that half your customers can't use.

Three.js renders in the browser with no install, no plugin and no app store. That is the whole proposition: a customer clicks a link and the product is there, on a phone, in a browser they already have.

WebGPU is the newer graphics API underneath, and Three.js can target it through its node material system and TSL. It matters for configurators in two specific ways: compute work moves to the GPU, and material authoring becomes composable rather than string-pasted GLSL. It is not a magic performance upgrade, and on a simple product viewer you will not see a difference. Where it earns its keep is scenes with many objects, real-time shadowing and lighting work, or heavy post-processing. I build so that WebGL remains the fallback: WebGPU where it is supported, WebGL where it isn't, the same product either way.

For AR, the honest position is that there is no single path. Android handles glTF through Scene Viewer; iOS wants USDZ for Quick Look; WebXR's immersive-ar session works on Android Chrome and on Vision Pro, but not on iPhone Safari. A configurator that promises "view it in your room" needs two export pipelines, not one, and that is a scope decision to make early rather than discover late. More on that on the WebXR development page.

Starting from the 3D instead of the rules. The model is the fun part, so it gets made first. Then the option rules arrive and the model has to be rebuilt to support them. Write the rules down first, in a spreadsheet, in plain language. If they can't be written down, they aren't decided.

Shipping every variant in one file. Twelve upholstery textures at 4K, all downloaded whether or not anyone selects them. Load the default, fetch the rest on demand.

Photoreal ambition on a mobile budget. Path-traced renders and a 60 fps mobile configurator are different products. You can offer both (real-time in the browser, a high-quality render on request), but pretending one is the other ends in a scene that stutters on the devices most of your customers use. That trade-off is the subject of the 3D product visualization page.

No fallback. WebGL fails: old drivers, locked-down corporate machines, low-power mode, a browser that blocklists the GPU. The page needs a still image and a sentence, not a black rectangle. The same applies to the configurator's own content. The product name, the options and the price should exist in HTML whether or not the canvas ever renders.

Treating it as a launch instead of a product. New fabrics arrive. Legs get discontinued. If updating the configurator means emailing a developer, it will drift out of date within a year and quietly stop being trusted by the sales team.

Measuring nothing. Which options do people try? Where do they abandon? A configurator generates useful product data and most of them throw it away.