A 3D product configurator lets users customise a product visually before buying. Select a colour, swap a material, add a component, and see the result rendered in real-time. The business case is straightforward: retailers using 3D product views report significantly higher conversion rates and fewer returns. Customers who can rotate, zoom, and customise develop confidence that static photographs cannot provide.
The rendering is the easy part. The hard part is the system behind it: syncing the 3D scene with product data, managing model variants, handling pricing and availability in real-time, and making it all load fast enough that users do not abandon the page.
3D Product Configurator
Select colours, materials, and leg styles to configure the chair in real-time. The Three.js scene updates material properties and swaps geometry instantly. Drag to rotate, scroll to zoom.
The Constraint: Combinatorial Explosion
A product with 5 colour options, 3 materials, and 4 components has 60 possible combinations. Photograph each from 6 angles and you need 360 images. Add a size option and it doubles. A 3D configurator renders any combination on demand from a single set of models.
The real constraint: The rendering is not the hard part. Modern GPUs handle PBR materials and environment reflections without breaking a sweat. The constraint is the asset pipeline: getting models from design tools into the browser at acceptable file sizes, with materials that swap cleanly, and geometry that performs on mobile devices.
Every decision in configurator architecture flows from this: how to decompose the product into swappable parts, how to prepare those parts for web delivery, and how to connect the 3D scene to the product database.
The Naive Approach
Standard tutorials demonstrate loading a model and rendering it. For product configuration, this typically becomes:
This works in a demo with one product and a fast connection. It fails in production where you have 200 products, mobile users on 3G, and a backend that needs to validate every combination against inventory.
The Robust Pattern: Model Architecture
A single base model with swappable components. Each configurable part is a named node in the GLTF scene graph. Materials are separate assets that can be applied to any compatible mesh at runtime.
Base Geometry
The product shape that does not change. Exported once, cached aggressively by the browser. This is the visual foundation.
Component Meshes
Named groups (seat, legs, armrest) that can be shown, hidden, or swapped. Each component variant is a separate small GLTF file loaded on demand.
Material Library
A set of PBR material definitions (colour, roughness, metalness, normal maps) stored as JSON with texture references. Applying a material means updating properties, not reloading geometry.
This decomposition means a colour change is instantaneous (material swap, no network request). A component change loads only the new component geometry (small file, fast load). The base model loads once and is reused across the entire configuration session.
GLTF Model Preparation
Models need deliberate preparation for web delivery. Raw exports from CAD or 3D modelling software are far too heavy for browser use.
Polygon budget
Target under 100,000 polygons for the complete configured product. Decimate high-poly source models. Use normal maps to preserve visual detail on simplified geometry.
Draco compression
Compress geometry with Google's Draco library. Typical reduction of 80-90% in file size. A 5MB model becomes 500KB.
Texture optimisation
Resize textures to the minimum resolution that maintains visual quality at the expected viewing distance. Use WebP or KTX2 compressed textures. A 4K texture on a component users see from 2 metres away is waste.
Total load budget
Target under 3MB for the initial configured product including all textures. Users on mobile connections will not wait for more. Load additional variant assets on demand.
Backend Integration
The configurator must talk to the product database. Configuration state lives in the application, not the 3D scene. The 3D scene reflects application state; it does not own it.
User selects option
Colour, material, or component
Frontend sends config
New state to backend API
Backend validates
Checks availability & rules
Returns pricing
Updated price & stock status
Scene updates
3D view & UI sync together
Each stage in this flow serves a purpose. Validation prevents invalid combinations (a walnut finish that is not available on the compact model). Pricing ensures users always see the correct total. The scene update is the visual confirmation that completes the interaction loop.
Example: furniture configurator. A sofa with 3 frame sizes, 8 fabric options, 4 leg styles, and optional armrests has 192 combinations. The base frame GLTF is 280KB (Draco-compressed from 4MB). Fabric changes swap a single material (instant). Leg changes load a 15KB component file. The backend validates that fabric X is available on frame Y, returns the updated price, and the scene reflects the change in under 100ms. Total initial download: 1.2MB including the HDR environment.
Option Validation
Not every combination is valid. The backend validates combinations and returns available options for the current state. Unavailable options are disabled in the UI, not hidden.
Inventory & Pricing
Each option affects price. Some options may be out of stock. The backend calculates the total and flags unavailable options so the frontend can update both the price display and the option states.
State Management
Configuration state is a plain object: { colour: 'walnut', material: 'leather', legs: 'tapered', size: 'large' }. This object drives both the 3D scene and the UI controls.
Validate the new state against available options.
Update the 3D scene (swap material, load component, adjust dimensions).
Update the UI (price, availability indicators, selected states).
Push state to the URL so configurations are shareable and bookmarkable.
The Asset Pipeline
The path from design file to browser-ready model determines both quality and performance. Neutral, consistent HDR lighting (not dramatic art direction) ensures materials render accurately for purchase decisions. Orbit controls need constrained angles and damping: users should not rotate upside-down or zoom inside geometry.
For e-commerce integration, map configurator options to product variants or line item properties. Generate a configuration screenshot with renderer.domElement.toDataURL() for the cart, and store the configuration ID server-side so support can see exactly what was ordered.
The Business Link
A 3D product configurator is a sales tool. The investment in model preparation, backend integration, and performance optimisation pays back through measurable business outcomes.
-
Higher conversion rates Customers who interact with a 3D configurator develop purchase confidence that static images cannot match.
-
Fewer returns Customers know exactly what they ordered. No surprises on delivery. The 3D preview matches reality.
-
Reduced photography costs New colours and materials are added as texture files, not photo shoots. The configurator renders any combination on demand.
-
Specification accuracy The configuration generates exact specifications for manufacturing. No interpretation of written orders. The system produces what the customer saw.
The technical complexity is in the integration, not the rendering. Three.js handles the visual output. The architecture challenge is connecting 3D to product data, inventory, pricing, and ordering in a way that stays maintainable as the product catalogue grows.
Build a Product Configurator
We build 3D product configurators that integrate with your product database, inventory system, and e-commerce platform. Models optimised for web delivery, real-time pricing, validated configurations, and a smooth experience across devices.
Let's talk about your configurator →