Building a 3D product configurator: how game-engine technology supplanted traditional rendering

The first 3D product configurator I built was for a UK furniture manufacturer with a catalogue of several hundred customisable products and a development overview, drafted by an external agency, that proposed a 360-day rendering schedule using Autodesk 3DS Max. The schedule was, in the strictest sense, achievable; it would also have required the business to hire two additional staff members for the singular purpose of operating the rendering software, and would have produced an asset pipeline that could not have absorbed the annual product update cycle that the business was contractually obliged to honour. The project, on those terms, was not viable.

The pathway by which the project nevertheless shipped — within the original release window, with a single developer rather than three, and with the full catalogue rather than the partial one that the agency had assumed — is the subject of the MRes research I completed at Manchester Metropolitan University in 2020. It is also the pattern that I have, in the four years since, refined and rolled out across configurator projects for several other UK businesses. This post is an attempt to articulate the pattern as I now understand it, and to make the case that game-engine technology, applied carefully, supplants traditional 3D rendering for product configurator development in essentially every commercial circumstance I have encountered.

The traditional pipeline and its incompatibilities

A traditional 3D rendering pipeline, of the kind that has dominated product configurator development since the technology became commercially available in the 1990s, treats each product image as the output of a discrete rendering operation. The 3D model is loaded into the rendering software (3DS Max, Maya, Blender’s Cycles renderer, Cinema 4D); the materials and textures are applied; the lighting is configured; the camera is positioned; and the renderer produces a single image, typically over a period of minutes per frame depending on the complexity of the scene and the quality of the renderer’s output. The output is then stored, sorted, named, and uploaded to whatever asset-delivery infrastructure the configurator’s front end consumes.

This pipeline has several properties that make it incompatible with the operational reality of most retail businesses. The first is its sheer slowness. The 360-day schedule mentioned above was not pessimistic; the original agency had estimated 282,320 individual product images, each of which would have taken approximately a minute to render on the hardware available at the time. The arithmetic is straightforward and unforgiving. The second property is that the slowness is poorly amortised; if the catalogue is updated mid-cycle, the rendering work is not modular and so frequently has to be partially redone. The third is that the pipeline assumes a particular skillset — competence in 3DS Max or its equivalent — that is rarely present in the existing staff of a manufacturing business and which is expensive to acquire externally.

The pattern I have come to recommend instead treats the rendering operation not as a discrete output but as a side effect of running an interactive application. The 3D models are loaded into a real-time game engine (in my work, Unreal Engine 4; the same approach is achievable in Unity); the materials are applied through arrays addressable by code; the lighting is baked once for the studio environment and reused across every product; the camera operates under programmatic control; and the rendering operation is reduced to a screenshot of the running scene, which the engine produces in milliseconds rather than minutes.

The rendering algorithm in outline

The rendering algorithm that the pattern depends upon is, at its core, a loop. The application instantiates a product, applies the first material combination to it, takes a screenshot, increments the material combination, applies it, takes another screenshot, and continues until every combination has been rendered. The rendered images are stored in a directory structure that mirrors the combinatorial structure of the product — one folder per product, one folder per view, one folder per colour element, with the individual image at the leaf of the path.

The algorithm runs in essentially the same time, regardless of how many combinations the product supports. The constraint is not the rendering itself, which proceeds at the engine’s frame rate (sixty frames per second, in the typical case); the constraint is the storage of the images, which is bounded by the speed of the disk rather than by anything intrinsic to the rendering. On the hardware I used for the original work — an NVIDIA GTX 1080 Ti, a consumer card that was already several generations old at the time of the project’s completion — the rendering of 282,320 images took approximately fifty hours rather than 360 days. The improvement, while it is somewhat expected when the underlying mechanism is described in this way, is consistently received with surprise when it is encountered for the first time in a procurement conversation.

What game engines automate that traditional renderers do not

The rendering speed itself is the most visible benefit of the pattern, but it is not the most consequential. The more consequential benefits, in my experience of shipping the pattern across multiple businesses, are the operational consequences of having the rendering pipeline live inside an interactive application rather than inside a batch-processing tool.

The first operational consequence is that the storage and naming of the rendered images becomes automatic. The rendering algorithm knows, at the moment of taking the screenshot, exactly which product, which view and which material combination it is rendering; the algorithm therefore writes the image to the correct path in the directory structure without any human intervention. The 30-day data-entry task that the original agency had estimated for sorting and uploading the rendered images was, in the game-engine pattern, eliminated entirely. The pipeline produces the images in the format the front end expects, in the location the front end reads from, with the names the front end resolves; nothing further is required.

The second operational consequence is that the addition of new materials, new colours, new products, or new views to the configurator becomes a matter of editing a data structure within the application rather than a matter of restarting the rendering pipeline from scratch. The rendering algorithm, when it runs, looks at whatever the current state of the data is and produces the corresponding images. If a new colour is added, the algorithm renders the new combinations; if a colour is removed, the algorithm produces fewer combinations on its next run. The annual update cycle that the business was obliged to honour — and which the original agency had estimated would require a six-month rendering window — was, in the game-engine pattern, a two-day operation.

The third operational consequence is that the configurator itself, in addition to being rendered into static images, can be operated as a real-time application in its own right. The same pipeline that produces the images for the catalogue’s long tail can serve, at high quality and full interactivity, as the configurator for the catalogue’s hero pieces. (For more on this division between heroes and long tail, see Configurators that pay for themselves.) Two distinct deliverables — the static-image configurator and the real-time configurator — are produced from a single asset pipeline, with implications for development cost that are difficult to overstate.

The architecture in some more detail

The application I built for the KTP project had a structure that has, with minor refinements, persisted through the subsequent configurator projects. The application is divided into several layers. The model layer holds the 3D meshes for each product, organised by colour-element groups (so that, for example, the panels of a desk are grouped separately from the legs, allowing each group to receive its own material at runtime). The material layer holds the texture and material definitions, addressable by string-indexed arrays so that the rendering code can request materials by name rather than by hard-coded reference. The product-instance layer holds the product-specific configuration — which material slots correspond to which colour elements, what the default state of the product is, what views the product supports.

The rendering algorithm operates on these three layers via a small piece of C++ code that exposes a “request screenshot” function to the engine’s higher-level scripting environment. The function captures the current state of the scene to memory, applies a transparency channel based on the absence of pixels in the rendered image, and writes the image to disk at the path computed from the current product, view and material state. The C++ implementation is necessary because the engine’s native screenshot function does not, by default, run during the play state of the application; the custom function works around this limitation in approximately fifty lines of code.

The web configurator that consumes the rendered images is, by comparison, a simple piece of JavaScript. It reads the image directory structure, presents the available products and their customisation options to the user via a small set of UI controls, and changes the displayed image in response to the user’s selections. The performance of the configurator is dominated by the size of the images and the speed of their delivery; on a competently configured CDN, the experience is essentially indistinguishable from a real-time renderer for the great majority of products.

What I would do differently in 2026

Several aspects of the original implementation are worth revisiting in light of the technology that has become available since the work was completed. Real-time ray tracing, which was unavailable on the GPU I had access to in 2018, would now eliminate the requirement to bake the studio lighting and would permit the rendering of reflections and ambient occlusion at considerably higher quality. The image format I used — TGA, the engine’s native format, which is needlessly large at 32-bit colour depth — would now be replaced with WebP or AVIF, both of which are mature enough to produce considerable storage and bandwidth savings without perceptible quality loss.

The application’s content-management layer, which in the original implementation required the operator to use the engine’s own UI to add or modify products, would in a 2026 implementation be exposed via a small custom interface running on top of the engine’s UMG widget system. The interface would expose the product, material, view and colour-element data as simple form controls, permitting the configurator’s content to be maintained by an editor with no engineering knowledge. The first version of the project did not include this interface, and the absence of it became, over time, the principal bottleneck in the project’s ongoing operation; later projects have included it from the outset.

An advisory close

The case for game-engine technology in product configurator development is, in my view, no longer one that requires advocacy. The pattern is now sufficiently mature that the businesses still building configurators on traditional rendering pipelines are doing so out of organisational inertia rather than out of any defensible technical objection. For any retailer scoping a 3D configurator project in 2026, it is recommended that the development overview specify a game-engine pipeline from the outset; the alternative, in essentially every case I have encountered, produces a project that either fails to ship at all or ships with a partial catalogue and an asset pipeline that the business cannot maintain.

The pattern is, in some sense, a small contribution; the underlying observation is simply that an interactive 3D application is, by virtue of producing images on demand, also a rendering pipeline. That observation has, in my experience, been worth approximately three hundred and ten days of engineering time per project. (For the broader question of whether the resulting configurator earns its asset cost commercially, see The 3D commerce boom is mostly demoware.)