The fundamental problem with 3D product configurators is not, as is often assumed, the technology. The technology has been mature for some years; commodity game engines, browser-native WebGL implementations, and the steady improvement of consumer GPU performance have between them solved the rendering side of the problem with considerable thoroughness. The fundamental problem is the asset pipeline. A glossy real-time configurator looks excellent in the demonstration video; if the brand has four thousand SKUs and each one requires a hand-tuned 3D model, the project will, with near-mathematical certainty, never reach fruition.
This observation is one I made for the first time during my MRes research at Manchester Metropolitan University, in the course of a 30-month KTP project to build a configurator for a UK furniture manufacturer with a catalogue of several hundred customisable products. The original development overview commissioned by the business proposed a 360-day rendering schedule using Autodesk 3DS Max; the schedule covered 282,320 individual product images and excluded a number of products on the grounds that their combinatorial complexity made them, in the original developers’ assessment, infeasible to include at all. The schedule was, in the strictest sense, achievable; it was also entirely incompatible with the commercial reality of a small manufacturing business that updates its product range each October and requires the configurator to be updated within a two-month window thereafter.
The project shipped on time, with a single developer rather than the proposed three, and with all products included rather than the partial catalogue that the original schedule had assumed. The pattern that made this possible — and which has, in the subsequent four years of rolling out configurators across other UK retail businesses, proven to be the most reliable approach to the asset-cost problem — is the subject of this post.
The economics that nobody discusses
Before describing the pattern itself, it is worth being explicit about the economic constraint that makes the pattern necessary. A 3D configurator project that requires a bespoke model for every SKU has a per-SKU cost that is largely fixed; whether the catalogue contains four hundred SKUs or four thousand, the cost of producing each individual model does not meaningfully decrease. Production studios that quote on this work typically estimate between two and five days of artist time per product, depending on complexity. At a representative day rate, this translates to a per-SKU cost of approximately one to two thousand pounds.
For a catalogue of four thousand SKUs, the implied cost is therefore between four and eight million pounds, before any consideration of the engineering work required to integrate the models with the configurator runtime. The number of UK retailers for whom this expenditure is even theoretically justifiable is small; the number for whom the conversion-rate uplift produced by a real-time configurator would recover the investment within a tolerable timeframe is smaller still. Most projects, presented with these numbers, do not proceed beyond the initial scoping conversation.
The dominant alternative — pre-rendering a finite set of product images using traditional rendering software, and serving them as static assets — does not solve the problem so much as it relocates it. The 360-day rendering schedule mentioned above was the consequence of precisely this approach. The asset cost is no longer borne in artist time per SKU but in render-farm time per combination; for products with a sufficient number of customisation options, the combinatorial explosion produces image counts that are, as in the case described, approaching three hundred thousand per project.
The parameterised-template pattern
The pattern that emerged from the KTP work, and which has since been refined across configurator projects for several other UK businesses, takes a different approach to the asset problem. Rather than producing a bespoke model for each SKU, the pattern begins with a parameterised template — a single base mesh whose geometry is constructed in such a way that the variable elements (dimensions, panels, trims, finishes, materials) can be modified at runtime through a set of well-defined parameters.
For the furniture catalogue described above, the parameterised template was a desk; the variable parameters included the desk’s width and depth (continuous variables sampled from a finite set of permitted dimensions), the colour and material of the work surface, the colour and material of the supporting structure, and the presence or absence of certain optional fittings. Approximately eighty per cent of the catalogue’s SKUs mapped to this template within an afternoon of work; the remaining twenty per cent — the hero pieces, the bestsellers, the products around which the marketing campaigns were built — received bespoke treatment, with individually authored models that could not have been adequately represented within the template’s parameter space.
The economic implication of this split is considerable. The eighty per cent of the catalogue that maps to the template is produced in approximately the same engineering time regardless of how large the eighty per cent is; for a catalogue of four hundred SKUs, the template handles three hundred and twenty of them; for a catalogue of four thousand, it handles three thousand two hundred. The hero pieces, which require bespoke work, are by definition a small absolute number — typically between thirty and a hundred — regardless of how large the parent catalogue is. The total asset cost therefore scales with the size of the hero set rather than with the size of the catalogue, which is the property that makes the pattern viable for large catalogues at all.
Why visitors do not notice
The objection most frequently raised against the parameterised-template pattern, when it is presented to brand and marketing teams, is that the visual quality of the parameterised products will be insufficient to compete with the bespoke renders that competitors are producing. This objection is, on the surface, a reasonable one; in practice, it appears to overestimate the granularity with which visitors actually compare products against one another.
The behavioural data we have collected from the configurator implementations indicates that visitors do not, in any meaningful sense, compare every product in a catalogue against every other product. The typical browsing session involves the viewing of a small handful of products — usually between three and seven — within a single category, after which the visitor either proceeds to a purchase decision or abandons the session entirely. The products visited within a single session are not selected at random; they are selected via a combination of category browsing, search results and recommendation surfaces, all of which heavily over-represent the bestsellers and the hero pieces. The long tail of the catalogue is rarely viewed at all, and when it is viewed it is almost never compared directly against the heroes that have already been viewed.
The practical implication is that the long tail of the catalogue can ride on the parameterised template at a visual quality somewhat below that of the heroes, and the great majority of visitors will not notice. The conversion-rate uplift produced by the configurator comes, in the data I have available, almost entirely from the long tail being present at all rather than from each long-tail item being maxed out to hero quality. (For more on the related question of when 3D commerce earns its asset cost and when it is theatre, see The 3D commerce boom is mostly demoware.)
The trap, which is also the most common failure mode
The parameterised-template pattern has, in my observation, one principal failure mode, and it is one that emerges not from a misunderstanding of the technology but from a misunderstanding of the visual hierarchy that the pattern depends upon. The asset team, having produced the parameterised template, is occasionally tempted to treat the template as the design ceiling for the catalogue — that is, to bring the hero pieces down to the visual quality of the template rather than holding the heroes above the template.
This is a critical error. The pattern functions on the assumption that the hero pieces are visibly, meaningfully better than the long-tail products that ride on the template; if the heroes are brought down to template quality, the visual hierarchy collapses, and the configurator as a whole begins to feel low-effort to the visitor. The conversion-rate uplift that justified the project in the first place dissipates, because the heroes are no longer doing the work that the heroes are supposed to do — which is to anchor the visitor’s perception of the catalogue’s overall quality at a high mark.
The mitigation, in the projects I have shipped, has been to formalise the visual hierarchy in the project’s design specification rather than leaving it to the asset team’s interpretation. The hero pieces are produced first, to a defined quality target; the parameterised template is produced second, to a defined quality target that is explicitly below the hero target. The two targets are reviewed independently and signed off independently. This is more process than is typical for a configurator project; it is, in my experience, the difference between a project that produces sustained conversion uplift and one that does not.
What this pattern does not solve
Two limitations of the pattern are worth noting explicitly. The first is that it works less well for products whose customisation is fundamentally geometric rather than material — that is, products whose variable elements change the shape of the product rather than its surface treatment. A modular sofa, for example, is more difficult to fit into a parameterised template than a desk, because the customer’s choices alter the topology of the model rather than just its textures. The second is that the pattern depends on having enough hero pieces to anchor the perception of the catalogue; for very small catalogues, with fewer than perhaps thirty SKUs, the distinction between hero and template products begins to lose meaning, and a fully bespoke approach often produces a better result.
For most retail catalogues in the range of one hundred to ten thousand SKUs, however, the parameterised-template pattern is the approach that, on the basis of the projects I have shipped, has the highest probability of reaching fruition within a tolerable budget and timeline. It is recommended that any retailer scoping a 3D configurator project insist on the pattern explicitly during procurement; the alternative, in most cases, is a project that does not ship at all.