Full Parametric Cabinet System

The problem: every SKU wanted a hand-made 3D model

A 3D kitchen visualizer has an obvious dependency: 3D models of the products. The traditional pipeline treats each product as an art asset — an artist models it, someone reviews it for dimensional accuracy, it gets optimized for the web, versioned, stored, and maintained. Then the product line updates and you do it again.

For a cabinet manufacturer, this pipeline isn't just expensive — it's structurally broken. A cabinet catalog isn't a list of objects; it's a combinatorial space. Widths step in increments. Heights and depths vary by line. Door styles, overlays, face configurations, and finishes multiply against each other. Modeling that space by hand means either restricting the visualizer to a subset of the catalog — undermining the product's purpose — or accepting an asset pipeline whose cost scales with the catalog itself.

We were building Vision, Rebode's kitchen visualizer, to production fidelity on the web — real-time rendering in the browser, on consumer hardware, for real purchasing decisions. The asset pipeline was on track to be the bottleneck for everything: catalog coverage, launch scope, and every future product line.

The insight: cabinets are already parametric

A cabinet is not free-form geometry. It's a box with rules. Its form is fully determined by a finite set of parameters — dimensions, construction style, door and drawer configuration, overlay type, finish — and those parameters already existed in structured product data.

So the system we built inverted the pipeline: instead of storing geometry and keying it to product data, generate the geometry from the product data, at runtime, programmatically. No per-SKU assets. No asset storage scaling with the catalog. A new product variant becomes a new row of data, not a new modeling task.

This is an old idea in CAD and a normal one in game development. The engineering challenge was making it hold up in a production web product where the output had to be dimensionally accurate — these are real products people buy — visually production-grade in lighting, materials and finish fidelity, and fast enough for real-time frame budgets on mid-range consumer devices, in the browser.

Designing the parameter model

The hardest design work wasn't the geometry generation — it was the parameter model. It had to satisfy two forces that pull in opposite directions.

General enough to cover the catalog. If the model can't express a product line's construction quirks, you're back to hand-modeling exceptions, and exceptions are where parametric systems go to die.

Strict enough that generated output never needs artist cleanup. The moment a human has to fix up generated geometry, you've rebuilt the manual pipeline with extra steps. Zero-cleanup was a hard requirement, not an aspiration.

The discipline that made this workable: treat the parameter model as a contract, and validate at the data boundary rather than patching at the geometry boundary. Malformed or out-of-domain product data should fail loudly at ingestion — not produce a subtly wrong cabinet that ships to a customer's design.

Integration with the rendering engine

The parametric system fed the Three.js / React Three Fiber rendering engine I architected for Vision. Generation and rendering were designed together, which is what made the performance story work.

• Geometry emitted in render-ready form. Because we controlled generation, we controlled the output's structure — geometry organized for efficient rendering rather than converted from an interchange format after the fact.
• Materials and finishes as a separate axis. Form parameters and finish parameters vary independently in the catalog, so they varied independently in the system — the same generated form re-skins across finishes without regeneration.
• The standard web-3D optimization pipeline still applied where static assets were involved: glTF with Draco mesh compression and KTX2 texture compression, post-processing tuned for fidelity within mobile GPU budgets.
• Frame-budget thinking throughout. A kitchen scene is many cabinets, not one. Generation had to produce geometry the renderer could draw at scale, on consumer hardware, inside a real-time budget.

What went wrong, and what it taught me

I designed the initial parameter model from the product specification and validated it against real catalog data afterward. That order was a mistake. The spec described the catalog as it was supposed to be; the catalog contained the products as they actually were — including legacy lines with construction rules the spec didn't fully capture. Real-world catalog data forced a schema revision mid-build.

The durable lesson, which I now apply to any system that replaces a manual pipeline: the messiest 5% of the existing inventory is the real spec. Start validation from the ugliest real data you can find, not from the documentation. If I built it again, the edge-case catalog would be day-one input, not a test phase.

Results

• Manual 3D asset creation, curation, and storage for the visualizer's catalog: eliminated. Product geometry became a function of product data.
• Hundreds of engineering and content hours saved — and, more importantly for the business, the asset pipeline stopped being the constraint on catalog growth. Extending coverage became a data problem, not a modeling project.
• Load times improved by roughly an order of magnitude once cabinets were generated instead of fetched as per-SKU assets.
• MasterBrand leadership discussed applying the system beyond Vision — across the parent company's wider catalog and visualization work.
• Shipped in Rebode's V1 launch, on schedule, in a year my team delivered zero P0/P1 defects across production releases and I earned the company's top performance rating.
• The system, and the Vision engine it feeds, are now led by the engineer I trained and mentored — the outcome I design for: systems and people that outlast my involvement.

Why this pattern generalizes

I keep returning to this project because the pattern applies far beyond cabinets. Any domain where assets are actually rule-governed variations of structured data — building products, configurable hardware, floor plans, network diagrams, financial instruments rendered visually — is a candidate for the same inversion: stop storing artifacts, start generating them from the source of truth. The web platform is finally fast enough to do it at production fidelity, in the browser, on the devices people actually own.

That's the lane I work in: the intersection of frontend architecture, real-time rendering, and structured data — building the systems that turn one into the other.