3D Configurator

This story has two separate chapters. The first is my MSc-by-Research work at Manchester Metropolitan University, completed in 2020. The second is a WebGL commerce platform I began developing in 2021 and later used across more than 35 retail sites.

I present them together because both deal with the same hard problem: how to describe a complex product, rule out impossible combinations and produce a visual result without turning every variant into manual production work.

The research problem

Highly configurable products can produce a huge number of visual states. Rendering and storing each state by hand is slow, expensive to maintain and easy to get wrong when the product changes.

My research tested whether game-development technology could automate more of that pipeline. The system combined structured product state with a real-time renderer so valid combinations could be produced repeatedly rather than built one image at a time.

What the system needed to do

1. Describe the product. Represent components, options, dependencies and exclusions as structured state.
2. Reject invalid combinations. Apply rules before rendering instead of producing impossible variants.
3. Automate the visual output. Make the renderer part of a repeatable pipeline.
4. Deliver the result. Give the catalogue, customer interface or sales process a reliable way to retrieve it.

The public thesis record supports the research direction and its conclusion that the tested method reduced manual production work and improved speed. It does not prove later commercial results, so I keep those claims separate.

---

From research to a WebGL commerce platform

In 2021 I started a separate platform project for live retail use. It let customers and sales teams choose valid options, see the result in real time and carry that configuration into a wider ecommerce or quote journey.

Product state came before scene state

The most important engineering decision was to keep the product configuration separate from the rendered scene. Product, material and interface choices could be normalised and checked before the WebGL layer displayed them.

• Compatibility rules could be tested without loading a 3D scene.
• Shareable links could reproduce a known, normalised product state.
• Conventional controls remained the primary interface instead of hiding the whole task inside a canvas.
• Fallbacks could preserve product choices when WebGL was unavailable.
• Commerce hand-off could pass an identified result into a basket, quote or sales workflow.

What changed between a demo and a production tool

The 3D view was only one delivery surface. The same state had to work on product pages, sales tablets, showroom displays, trade-show demonstrations and links shared with customers. Each surface brought different performance, accessibility, network and hand-off constraints.

Production readiness therefore started with operational questions: Are the combinations valid? Is the product data accurate? Does it work on the agreed devices? Is there an understandable non-3D route? Does the basket or quote contain enough information to fulfil the order?

Conversion and revenue analysis matter, but only after those foundations are working and the measurement has a defined baseline. I do not use an unpublished portfolio average as a promise for another retailer.

How this shapes my work now

The research and the later platform had different stakeholders and ownership, but the technical lesson connects them: product configuration is a system of state, constraints and repeatable output.

That is why my discovery work begins with rules, data ownership and the order hand-off—not with a rendering-library choice. The visual layer matters, but it has to sit on a product model the rest of the business can trust.