How to Make a 3D Configurator That Weighs Gummy Bears Live

If you want to know how to make a 3D configurator that people actually play with, start with one rule: the 3D must change a number the user cares about. In my Haribo Pick & Mix experiment, every gummy bear you drop into the bag is a real physics body, it lands on a digital scale, and the grams and the price update as it settles. Under the hood it is three.js for rendering, Rapier for physics, a custom jelly shader for the bears, and sound synthesized in the browser. Below I walk through each layer as it exists in the shipped build, the design decisions that matter more than the shaders, where AI tools fit in, and when you should not build a configurator this way at all.

What the Haribo pick and mix build actually does

Open the Haribo Pick & Mix experiment and you get a candy store page: six flavours (Strawberry, Orange, Lemon, Green Apple, Pineapple, Raspberry), four bag sizes, and a transparent bag sitting on a scale. Tap a flavour and one bear drops in. Hold the flavour and it pours. Click a bear in the bag to take it out. A "Mix for me" button fills the bag at random, a "Shake bag" button shakes it, and "Add bag to cart" seals the bag, prints a ticket number and sends it to a cart with a delivery line. It is a concept prototype, not affiliated with Haribo, and the checkout is a demo. The page says so in the footer, and I think every concept should.

What makes it a configurator rather than a toy is the pricing model. Each bag size has its own rate per 100 g: the 150 g Snack bag is €2.39 per 100 g, the 300 g Share bag €2.19, the 500 g Party bag €1.99 and the 1 kg Hoard €1.79. The total is simply the net weight on the scale times the rate. Each bear weighs a little differently, between 2.0 and 2.6 g in the code, so the number you see is never a round multiple. That tiny imperfection is what makes the scale feel real. I built it with Figma, Claude and the Figma MCP for the layout, then three.js and Rapier for the part a design file cannot express. It is one of my AI design experiments, all of them working builds rather than mockups.

How to make a 3D configurator: the five layers in this build

People imagine a 3D configurator as one big model viewer. In practice it is layers, and each layer answers a different question. Here is how they stack in the gummy bear build, read straight from the shipped bundle.

Layer 1, the product: a gummy bear modelled as a distance field

There is no bear model file. The bear is a signed distance function: a set of ellipsoids and capsules (body, head, ears, snout, arms, legs) joined with smooth unions, then turned into a mesh with marching cubes on a 52 by 52 by 52 grid. After polygonising, the build merges duplicate vertices and computes normals. One more pass marches a ray from each vertex inward through the distance field and stores how far it travels before leaving the bear. That per-vertex "thickness" value is the key to the next layer. Modelling in code instead of Blender was a deliberate choice: the bear needs to be built once, instanced hundreds of times, and shaded with data that a normal GLTF export does not carry.

Layer 2, the look: light that passes through jelly

A gummy bear is translucent, so an opaque material looks like plastic. The build draws each bear with three instanced meshes that share the same transforms. The first is an absorption pass: it uses Beer-Lambert absorption, where transmitted light equals exp(-sigma times thickness), and renders with multiply blending so the page behind shows through the bear, tinted by its flavour. Each flavour is defined by a deep colour that gets converted into absorption coefficients, so Raspberry absorbs much more light than Pineapple. The second is a depth-only pass so bears sort correctly inside the bag. The third is a glossy pass on a three.js physical material with clearcoat, plus an emissive term scaled by thickness to fake subsurface glow. On top of all that sits a sugar-grain shader: two skewed lattices of tiny grains with sparkle, so the grains never line up in rows. None of this needs a texture file.

Layer 3, physics: up to 560 bears in a bag with Rapier

Every bear in the bag is a dynamic rigid body in a Rapier world. Its collider is a convex hull built from a subsample of the bear mesh vertices, with friction, a little restitution, continuous collision detection so fast bears do not tunnel through the bag wall, and linear and angular damping so the pile settles instead of jittering forever. The bag itself is a kinematic body: the code moves it directly when you shake, and the bears respond. The world caps at 560 bears, which is more than the 1 kg bag holds. When you hold a flavour, the pour starts at one bear every 280 milliseconds and accelerates toward one every 50 milliseconds, which is why holding feels like tipping a jar rather than clicking fast. "Mix for me" rolls a random weight per flavour and drops a bear every 34 milliseconds, or every 22 milliseconds for bags over 600 g. Each bear also carries a small spring for jelly wobble, kicked on impact and rendered as squash and stretch along the impact axis. Gravity, friction and the wobble stiffness are hand-tuned constants, not real-world values, because the bag is not modelled at real scale.

Layer 4, the scale: a number that settles and beeps

The reading on the scale is not the raw sum of bear weights. It is a spring that chases the real total, snaps when it is within 0.05 g, and shows a STABLE light only when nothing has changed for 700 milliseconds. When the reading becomes stable the scale beeps, a short square wave at 2730 Hz, like a real kitchen scale. Lift the bag to shake it and the scale reads zero, because that is what a scale does when you lift the bag off it. The display itself is a seven-segment digit renderer drawn on a canvas and used as an emissive map on a black glass plate, with TARE and NET labels. This is the layer most 3D configurators forget: the 3D is only convincing if the number attached to it behaves like a physical instrument.

Layer 5, sound synthesized in the browser

The experiment item lists ElevenLabs among its tools, and in the shipped bundle every sound you hear inside the bag is generated at runtime with the Web Audio API. There are no audio files. The crinkle is a bank of filtered noise bursts, the plop of a bear landing is a short noise burst plus a low sine thump with ten random variants, the taps are tiny filtered clicks, and a synthetic reverb impulse runs through a convolver at low gain so the sounds sit in a space. A compressor on the master bus keeps a pour from clipping, a limiter allows at most three plops per 100 milliseconds so a fast pour becomes a rush rather than a drum roll, and each hit gets a random stereo pan. The audio context unlocks on the first tap, and a toggle saved in local storage lets people turn sound off. If you want the design argument for sound in UI, I made it in my post on micro interactions with sound and physics, built around a bank card you shatter to unfreeze.

Three ways to make a 3D configurator, compared

Not every product needs physics. Here is how I would choose between the common approaches, based on what I have built and what I would recommend to a client.

Approach	Good for	Limits	When I would pick it
Pre-rendered image swaps (a photo per option)	Colours, finishes, a few fixed angles; works on any store platform	Combinations explode fast; no free camera; no motion	Fewer than a few dozen combinations and a tight budget
Hosted 3D tool embed (Spline and similar)	A real 3D model with a free camera and simple variant switching, built visually	Harder to tie to live pricing logic, custom physics or custom shaders; you depend on the host	A marketing page where the model is the hero and the logic is light
Custom three.js, with Rapier when needed	Anything where the 3D changes a number: weight, price, fit, quantity; custom materials and sound	You need a design engineer; performance work on mobile; longer build	The configurator is the product, like a pick and mix, a floor plan, or a made-to-measure item

If you are weighing the middle row against the last one, I wrote a direct comparison of Spline vs three.js with the trade-offs for product teams.

The design decisions that matter more than the shaders

I could have shipped the bears without the scale and it would still have looked impressive for ten seconds. The decisions below are what keep people filling bags for minutes, and they are the part I would carry into a real e-commerce configurator.

Price per 100 g drops as the bag gets bigger, and the rate is printed next to the weight at all times. The user never has to compute anything; the configurator shows the consequence of the choice. The bag fills bear by bear with a hold-to-pour gesture, so the cost of a wrong click is one bear, and the minus button removes the last bear of a flavour. When the bag is full the ticket shakes and a message says the exact weight and tells you to pick a bigger bag or check out: a clear next action rather than a silent refusal. "Mix for me" exists because a configurator with six options and a blank bag is a cold start; a random fill gives people something to edit, and editing is easier than creating. Sealing the bag plays a chime and prints a ticket number, which is the small ceremony that makes "Add to cart" feel like something happened. That same thinking, show the consequence first and ask for the commitment second, is what moved activation from 13% to 65% on the creator platform I led design on at ViewStats, which I break down in the ViewStats case study. People rarely want more information. They want clarity.

Where AI fits when you make a 3D configurator

The tools listed on this experiment are Figma, Claude, Figma MCP, three.js, Rapier and ElevenLabs. The page layout, the flavour keys, the ticket and the cart started in Figma and went to code through the Figma MCP with Claude. The distance field bear, the absorption shader, the Rapier setup and the audio synthesis are the kind of work I did in the code with Claude, iterating on constants until the pour felt right. What AI did not do is decide that the scale should beep when stable, that lifting the bag should zero the reading, or that the pour should accelerate. Those are judgment calls, and they came from thinking about how a real sweet shop feels. AI replaces production work, not judgment. I wrote about what that shift means for the role in the future of UI UX design with AI, and the honest version of the replacement question in will AI replace product designers.

This is also the clearest example I have of why a product designer who ships code gets a different result from one who hands off a Figma file. The wobble spring, the pour acceleration and the 700 millisecond settle time are not things you can annotate in a design file. You find them by changing a number, reloading, and feeling the difference. The same loop is what let me open pull requests at ViewStats instead of writing tickets. If that path interests you, my guide to what a product designer does covers where the role is heading.

When you should not build it this way

A custom three.js configurator is the right call only when the 3D drives a number or a decision. If you sell a sofa in eight fabrics, image swaps or a hosted 3D embed will convert as well at a fraction of the cost. Physics in particular is rarely worth it outside of products that are sold by quantity, weight or arrangement. Mobile performance needs real attention: this build caps the pixel ratio at 2, uses a 2048 shadow map and a single key light, and still asks a lot of an older phone with hundreds of bears in the bag. Accessibility needs its own pass: the flavour keys here respond to Enter and Space and the minus buttons have labels, but a 3D scene is invisible to a screen reader, so every number the scene produces must also live in the DOM, which is why the ticket on the right repeats weight, bear count, rate and total as text. And a real store adds inventory, returns and tax, none of which a prototype has to face. If you are building a 3D configurator for a product and want a second opinion on which of the three approaches fits, you can hire me as your product designer or just send the brief and I will tell you which row of the table you are in.

FAQ: how to make a 3D configurator

What tools do you need to make a 3D configurator for a website?

For a custom build: three.js for rendering, a physics engine like Rapier only if objects need to move on their own, and the Web Audio API if you want sound. The official three.js documentation and the Rapier site are the two references I keep open. For a lighter build, a hosted 3D tool with an embed is enough. Design the interface in Figma first either way; the 3D canvas is only one element on the page.

Does a 3D product configurator need physics?

Usually not. Physics earns its place when quantity, weight or arrangement is part of the purchase, as with pick and mix sweets, a shelf you fill, or a box you pack. For colour and material choices, physics adds cost and frame drops without changing the decision.

How do you connect a 3D scene to live pricing?

Keep the pricing logic outside the 3D code. In this build the scene only reports count and grams per flavour through a callback; the page computes weight times rate per 100 g, renders the ticket, and decides when the bag is full. That separation means you can test the price logic without a GPU and swap the 3D layer later.

Is three.js good for e-commerce configurators?

Yes, when you have someone who can own performance and the shader work. It is open source, runs everywhere WebGL does, and lets you build materials, like translucent jelly, that no off-the-shelf viewer offers. The cost is engineering time and a mobile performance budget you have to respect from day one.

Try it, then copy the checklist

Fill a bag on the live page, hold a flavour until the pour speeds up, and watch the scale settle and beep. Then, for your own configurator, check five things: the 3D changes a number the user cares about; the number behaves like an instrument, with settling and feedback; every option shows its consequence before the commitment; the empty state gives people something to edit; and everything the scene says is also in the DOM as text. Get those right and the shaders are the easy part. If you want to see more builds like this, the experiments page has the full set, and the contact page is the fastest way to reach me about a configurator of your own.