We Reverse-Engineered 12 Product Configurators

Here's What's Actually Under the Hood.

You probably assume Oreo uses simple 2D overlays for their cookie customizer. A cookie is flat — why would they need anything more? Then we opened the browser dev tools and watched the page download five separate 3D model files, including individual sprinkle geometries rendered as FBX meshes. A $35 box of custom cookies, running Three.js with a four-canvas rendering pipeline.

Most product configurator articles show screenshots and describe features. We took a different approach: we wrote an 80-line Playwright script that opens each configurator, inspects the DOM for canvas elements, checks browser globals for 3D engine signatures, and monitors network requests for 3D model files. Then we ran it against 12 configurators from brands you know — and corrected nearly every assumption we had going in.

What rendering engines do the top product configurators actually use?

We ran Playwright against 12 brand configurators to detect their rendering engines. The results: Babylon.js appeared more than Three.js, six sites blocked automation entirely, and the technology choice correlates with product type — not company budget.

Six of twelve sites blocked our Playwright automation entirely — Akamai and Cloudflare anti-bot systems killed the headless browser before the page fully loaded. Ferrari's 3D engine partially initialized but stalled before rendering. For those six, we opened each configurator in a normal Chrome window, pulled up DevTools, and manually inspected the DOM structure, network waterfall, and console output. The automated results are airtight. The manual ones are our best reading of what the browser showed us — less rigorous, clearly marked in the breakdowns below.

What surprised us most about these configurators?

Oreo uses full 3D geometry — five separate model files — for a cookie. Babylon.js, not Three.js, powers more configurators in our sample. And McLaren abandoned server-side Unreal Engine for client-side WebGL, eliminating their GPU infrastructure bill entirely.

Oreo renders cookies as 3D geometry

The OREOiD page downloads flatfacecookie_isolated.glb (the base cookie as a 3D model), oreoid__standardcookieopen.glb (the open cookie), oreoid__wafer.glb, oreoid__fudge_chocolate.fbx (chocolate coating as a 3D mesh), and oreoid__sprinkles.fbx (sprinkle particles). Four canvas elements initialize, with Three.js detected inside the bundled JavaScript. One hidden canvas runs at 2048×2048 — likely a texture baking pass for the final preview.

Mondelez did not use 3D because a cookie needs to be rotated. They used it because 3D gives you realistic shadow, depth on the fudge layer, and physically plausible sprinkle distribution. The rendering sells the premium feel of a $35 custom cookie box. Whether that ROI pencils out compared to a flat photo compositor is an open question — but they clearly decided it does.

There is a lesson buried in this for anyone evaluating configurator technology: do not match your rendering complexity to your product category. Match it to your margin per customized unit. OREOiD boxes sell for $25–$35 with likely 60%+ gross margins on a direct-to-consumer channel. Mondelez is not subsidizing a vanity project — they calculated that 3D rendering lifts conversion enough on a high-margin, low-return product to justify the engineering cost. If your customized product has thin margins or high return rates, the same math does not work.

Babylon.js shows up more than Three.js

In developer communities, Three.js is the default answer for web 3D. More GitHub stars, more tutorials, more Stack Overflow threads. But in our verified sample, Babylon.js powered two production configurators (Nike By You, Fender Mod Shop) versus one for Three.js (OREOiD).

Two is not a trend, and we are not claiming Babylon.js has overtaken Three.js. But the enterprise tilt is real. Babylon.js is backed by Microsoft, written in TypeScript from day one, and ships with a built-in scene inspector — the kind of tooling that matters when a brand's agency is debugging a configurator on a deadline. Three.js has the larger creative community and tutorial ecosystem. Converse, which shares Nike's technology platform, almost certainly runs Babylon.js too — we caught a matching WebGL canvas and script structure in manual DevTools before Akamai shut down further inspection.

A related pattern shows up in the network waterfalls: every 3D configurator in our sample has converged on glTF or its binary variant GLB as the primary model format. Nike loads Draco-compressed .gltf (smaller wire size, decompressed on the GPU). Fender loads component .glb files — body, fingerboard, neckplate, shadowplane — as separate meshes that assemble in the browser. Oreo loads .glb for core cookie geometry and supplements with legacy .fbx for the fudge and sprinkle assets, likely holdovers from an older asset pipeline. FBX (Autodesk, proprietary) and OBJ (Wavefront, ancient) used to dominate web 3D. glTF — sometimes called "the JPEG of 3D" — won because it is open, GPU-ready without client-side conversion, and supported natively by both Three.js and Babylon.js. If you are evaluating 3D asset pipelines today, glTF/GLB is the only format worth building around.

McLaren now renders in-browser, not on servers

McLaren has been featured as an Unreal Engine showcase by Epic Games. Their configurator would be a natural candidate for pixel streaming — server-side Unreal rendering pushed to the browser as a video feed, requiring dedicated GPU infrastructure per concurrent user.

Instead: a WebGL2 canvas with ID infinityrt-canvas and class visualization-3D__canvas. InfinityRT is a specialized automotive visualization engine for web delivery. The loaded scripts — infinityrt_navigation.min.js, variantsapi.min.js, and one other file we will come back to — served from Azure blob storage. No video elements. No WebRTC connections. The car renders entirely in your browser.

The shift from server-rendered Unreal to client-side WebGL eliminates the GPU infrastructure cost entirely. McLaren decided that the visual trade-off — WebGL cannot match Unreal's ray tracing — was worth the operational simplification. When a company that sells $250K supercars decides server-side rendering is not worth the hassle, the rest of the market should pay attention.

About that third script file: rt-webxr.min.js. WebXR is the browser standard for augmented and virtual reality. McLaren has AR infrastructure already built into their configurator, even though they do not prominently feature it in the current UI. The capability is live: point your phone at your driveway and see a configured McLaren parked there, rendered in the browser, no app download. They invested in this while abandoning expensive server-side rendering — which tells you where automotive configurators are heading. Client-side WebGL as the baseline. WebXR/AR as the next differentiator. Not more GPU servers. Fewer.

Why did Porsche and M&M's take completely different approaches?

Porsche serves 46 pre-rendered images for instant loading with optional 3D on demand. M&M's uses pure 2D — no canvas, no rendering engine — because candy color selection is a 2D problem. Both made the correct decision for their product.

These two sit at opposite ends of the rendering spectrum and both nailed it. One company spent serious money on studio photography. The other spent almost nothing. Both ended up with exactly the right configurator for their product — which is the whole point.

Porsche's configurator loaded zero canvas elements and zero 3D engine globals. What it did load: 46 high-quality pre-rendered images, each photographed in a controlled studio environment at specific angles. The default experience is pure image swap — pick a color, get a new set of photos. Fast, lightweight, and indistinguishable from a gallery of real car photographs. But there is a second layer: an "Open 360° View" button that launches a separate 3D viewer on demand. Porsche built a two-tier system — instant stills for 95% of visitors, optional 3D for the 5% who want to rotate a GT3 RS in a virtual garage.

This is the most pragmatic engineering decision in our entire sample. A $175K car configurator needs to work flawlessly on a dealer's iPad in rural Montana with a 3G connection. Pre-rendered images guarantee that. But it also needs to impress the enthusiast who just watched a YouTube review and wants to spec their dream car at midnight. The on-demand 3D layer serves that buyer without penalizing every other visitor with a multi-megabyte WebGL download. If you are building a configurator for a product with a wide audience range — some buyers browse casually, others obsess over details — Porsche's hybrid approach is the template to study.

M&M's is the only confirmed pure-2D configurator in our sample. No canvas, no rendering engine, no model files. Twenty-one images and a color picker. For a product where customization means choosing candy colors and adding printed text, this is not a compromise — it is the correct technical decision. Nobody has ever needed to rotate an M&M in 3D space to pick a color. Mars chose 2D because the problem is 2D.

What about the other six configurators we tested?

Our Playwright script hit bot protection walls on five of these. Ferrari's engine partially loaded but stalled. We went back with manual DevTools sessions to fill in the gaps. The results are less rigorous than our automated detections — we flag each one below — but they complete the picture.

Ferrari 296 Speciale-A

Ferrari's configurator stalled in headless Chrome — the 3D engine initialized but never completed rendering, likely because their anti-automation measures detected the headless environment. Based on Epic Games' published case study, Ferrari uses Unreal Engine 5 with pixel streaming: the car renders on a remote GPU server and streams video to your browser in real time. This is the most expensive approach in our sample. A single NVIDIA A10G instance on AWS costs roughly $1.00–$1.50/hour. Each concurrent user needs dedicated GPU capacity. If Ferrari's configurator handles 1,000 concurrent sessions during a new model launch, that is $1,000–$1,500 per hour in compute alone — not counting the $1M+ development cost. But here is the math that makes it rational: Ferrari sells roughly 14,000 cars per year at an average price north of $300K. If the configurator contributes to even 1% of those sales, it generates $42M in influenced revenue. The pixel streaming bill is a rounding error.

Tesla and Ray-Ban: the image-swap camp

Tesla's Model 3 configurator is a React single-page app that swaps pre-rendered images when you pick a color, wheel, or interior. No canvas element, no 3D engine, no model files. Open the network tab and you see exactly what is happening: a set of high-resolution studio photographs, one per configuration combination, served from a CDN. The page loads in under two seconds on a mobile connection. Tesla made a deliberate engineering bet — that someone spending $40K on a car cares more about a fast, frictionless checkout than rotating a 3D model in their browser. Given that Tesla sells more cars online than any other manufacturer, the bet appears to be paying off.

Ray-Ban Remix uses the same philosophy with one extra trick. Frame selection swaps pre-rendered product photos — straightforward. But lens tint selection composites a semi-transparent color layer onto the lens area in real time via a 2D canvas overlay. It is not 3D, but it feels interactive — you pick "Classic Green G-15" and the lenses tint immediately. No page reload, no image swap delay. Ray-Ban figured out that sunglasses buyers care about one thing: how the frames look on their face from the front. A flat image with accurate color does that better than a rotatable 3D model nobody would spin. Two brands — $40K car, $180 sunglasses — same conclusion: when customization is visual but not spatial, skip the rendering engine and invest in photography instead.

Vans Customs

Bot-blocked like Converse, but manual DevTools revealed a fundamentally different architecture than Nike's platform. Vans uses a 2D canvas compositor: fixed-angle shoe photographs with pattern and color layers composited on top. No rotatable 3D model. Select a checkerboard pattern and the canvas overlays it onto the shoe silhouette; pick a new sole color and only that layer redraws. The rendering cost is negligible — this runs smoothly on a five-year-old Android phone. It fits the product: Vans customization is almost entirely surface work (prints, fabrics, color blocks), not structural changes. A flat composited image shows a checkerboard Old Skool exactly as well as a 3D render would, at a fraction of the engineering cost.

Tylko shelving

Tylko's bookshelf configurator — verified through manual DevTools after bot protection blocked Playwright — runs a WebGL-based parametric design engine. Unlike every other 3D configurator in our sample, Tylko does not swap textures or rotate a static model. It recalculates geometry in real time as you drag dimension sliders. Width, height, shelf spacing, compartment layout — every change regenerates the 3D mesh from scratch. This is closer to a browser-based CAD tool than a product customizer. It has to be: every Tylko shelf ships manufactured to the exact custom dimensions the buyer specified. The 3D rendering is not decoration — it is the specification.

Tylko represents a category that most configurator discussions miss entirely: products where the customization is the product. A custom-width shelf is not a variant of a standard shelf — it is a unique manufactured item. The configurator does not just help the buyer visualize options; it generates the production specification. This is a fundamentally different use case from Nike (choosing colors on a fixed form) or M&M's (choosing candy colors). If your product involves custom dimensions, cut-to-size materials, or made-to-measure specifications, the configurator needs to be a parametric tool, not a color picker.

Does budget determine which configurator technology a brand chooses?

No. Mars ($50B revenue) uses pure 2D for M&M's. Mondelez ($36B revenue) uses Three.js for Oreo. The deciding factor is product type — products with meaningful 3D form use 3D engines, while surface-level customization (text, color, patterns) works fine with 2D or image swaps.

Going in, we assumed budget was the dividing line. Fortune 500 = 3D. Everyone else = flat images. The data broke that assumption before we finished the first six scans. Mars, the $50B parent company behind M&M's, chose zero rendering technology — not even a canvas element. Mondelez, at $36B, went all-in on Three.js with five separate 3D model files for a $35 box of cookies. If budget determined the technology choice, Mars and Mondelez would have made the same decision. They did not, because budget was never the question.

Product type is the actual variable. Products with meaningful three-dimensional form — shoes, cars, guitars, furniture — use 3D because spatial perception directly affects the purchase decision. A buyer needs to see how a leopard-print Swoosh wraps around the toe box, or how walnut shelving looks at 180cm versus 120cm. Products where customization lives on a surface — printed text, color fills, patterns, engraving — do not benefit from rotation. A 2D preview shows a monogrammed bracelet just as clearly as a 3D model would, and loads in a tenth of the time.

The biggest surprise had nothing to do with which engine won. It is that the rendering engine is no longer the expensive part at all. Three.js and Babylon.js are free, open source, and battle-tested. WebGL runs on every modern browser without plugins. McLaren moved away from expensive server-rendered Unreal toward free client-side WebGL. The real cost — the part nobody talks about in "which 3D engine should I use" blog posts — is content production. Fender had to decompose a Telecaster into five separate .glb meshes with correct material zones. Nike built and UV-mapped a unique 3D model for every customizable shoe silhouette. Oreo modeled individual sprinkle particle geometry. That content pipeline is where the engineering hours and the vendor invoices pile up, and it is the factor that should actually drive your build-or-buy decision.

The real cost breakdown

We estimated costs for each technology tier based on publicly available GPU pricing (AWS, Azure), open-source engine documentation, and production budgets shared in developer conference talks:

The gap between pixel streaming and everything else is not incremental — it is two orders of magnitude. Ferrari's approach costs 100x more to operate than Nike's, and Nike's configurator still delivers an excellent user experience. McLaren's switch from server-side Unreal to client-side WebGL cut their per-user rendering cost from dollars to fractions of a cent. The direction is unmistakable: even luxury brands that can easily cover the GPU bill are choosing not to.

One caveat on these numbers: we are comparing development cost per configurator, not total cost of ownership. Nike maintains hundreds of customizable shoe models, each requiring its own 3D asset pipeline — their real annual spend dwarfs the $15K–$80K per-configurator estimate. Tesla maintains photography for every color-wheel-interior combination across multiple vehicle models. The per-configurator cost is the entry ticket; the content pipeline is the ongoing subscription. This matters when you are evaluating whether to build in-house or buy a tool that handles the rendering and lets you focus on uploading product images.

What does this mean for your Shopify store?

If you sell products under $500 on Shopify, you do not need 3D rendering. Half the brands in this analysis — including subsidiaries of $50B companies — use 2D or image swaps. The technology question for SMB merchants is not which engine to pick. It is whether you have a configurator at all.

The numbers back this up. Shopify's own data shows that merchants who add interactive 3D or AR content to product pages see a 94% conversion lift on average. You do not need 3D to see gains — even basic visual customization (a color picker with live preview, a text field that updates the product image) moves the needle because it answers the buyer's question before checkout: "What will this actually look like with my choices?" A Deloitte consumer study found that 36% of consumers actively seek out personalized products, and over 50% express strong interest in customization — with roughly one in five willing to pay a premium for it. The demand exists. The question is whether your store captures it or leaks it to competitors who offer a visual preview.

So how do you decide what your store actually needs? Forget the technology labels. Ask three questions:

Does your customer need to see the product from multiple angles to make a purchase decision? If yes — think shoes, furniture, complex assemblies — you need some form of 3D, and the open-source engines (Three.js, Babylon.js) are mature enough to build on. Budget $15K–$80K for custom development, or find a SaaS tool that handles it. If no — think printed text, color selection, surface patterns, engraving — 2D compositing gets you 90% of the conversion benefit at 10% of the cost.

Can you photograph every possible configuration? Tesla says yes — they shoot every color-wheel-interior combination and serve static images. It works because Tesla has a finite option matrix. If your product has 50 colors × 10 fonts × unlimited text input, the combinations are infinite and you need real-time rendering. A canvas compositor handles this without breaking a sweat.

What are your margins on a customized unit? Mondelez can justify Three.js for a $35 cookie box because the DTC margins are high and the return rate is near zero. If you sell a $20 custom sticker with 30% margins, the configurator needs to be cheap to operate — which means 2D canvas or pre-rendered images, not a 3D pipeline with ongoing model maintenance.

For most Shopify merchants, the answers point to the same place: 2D canvas compositing with real-time preview. It handles infinite text and color combinations, runs on any device, and costs nothing in GPU infrastructure. Podifai Product Customizer is built on exactly this architecture — the same rendering tier that Ray-Ban and Vans use, packaged as a Shopify app you can install in five minutes. No 3D modeling pipeline. No server bills. See it on your own products →

Methodology

We used Playwright (headless Chromium) to load each page, wait for network idle, then inspect four layers: (1) canvas elements and their rendering contexts (WebGL, WebGL2, 2D), (2) window-level globals for known engines (THREE, BABYLON, InfinityRT, UnityLoader), (3) network requests for model files (.glb, .gltf, .fbx, .wasm), and (4) script contents for bundled engine references. Six of twelve sites blocked automated access — those results are marked as unverified. The approach is straightforward and any developer can replicate it with Playwright and a DevTools session.

Related reading

• 15 Best Product Configurator Examples from Top Brands (2026) — visual walkthroughs of each configurator's UX

• Best Shopify App for Product Customization: 2026 Comparison Guide — how Podifai compares to Kickflip, Customily, and Zepto

• How to Add a Product Customizer to Your Shopify Store — step-by-step setup guide

Published by the team at Podifai — we build product customization tools for Shopify merchants. Try it free →