The configurator in numbers
The budgets are a design choice, not a standard: Phase 17 explains where such limits come from. The part size is an estimate (the 33 KiB bike divided by its 11 parts).
Design a 3D product configurator for thousands of variants: split the product into parts instead of one model per variant, deliver them from a CDN with fingerprinted names, budget per device class, load progressively with fallbacks, and keep it accessible and measurable.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 4 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Estimate the first-view download for the showroom: three.js, the 6 default parts, the decoder and one environment map.
A customer shares a link to their bike. What must the URL hold, and what happens when a part in it no longer exists?
Explain it without notes
Why split a configurable product into part models instead of one model per variant?
How do you make sure customers get a new model version immediately, while models stay cached?
Console
(nothing was printed)Expected console output
possible bikes (SKUs): 6,912
one model per SKU: 6,912 files, 0.2 GiB to build and store
one model per part: 18 files, 0.05 MiB; paint is a material, not a file
a customer's first view: 6 part files, about 18 KiB
desktop budget 200 calls, 1,000,000 triangles, 256 MiB, ratio 2: fits
mid phone budget 100 calls, 300,000 triangles, 64 MiB, ratio 2: fits
low-end phone budget 50 calls, 100,000 triangles, 32 MiB, ratio 1.5: fits