All projects

Case study

Kerf

A furniture workshop exports a kitchen project from PRO100, answers a short questionnaire and gets photographs of that exact kitchen. Not one like it — this one: with the dimensions and the boards the client will actually receive.

Client
Own product, Kazakhstan
Years
2026 — ongoing
Scope
Product management, development, render pipeline, generative-model integration
Stack
Python, Blender and Cycles, FLUX.2, Flask

The problem

A kitchen is sold before it exists, and it is sold with a picture. The usual route to that picture runs through a designer: first a beautiful visualisation appears, then someone tries to reproduce it in PRO100 — and gets about halfway. The client buys one thing and receives another, and finds out on installation day.

We reversed the order. The source of truth is the workshop’s project, not the visualiser’s imagination. The picture is made from the plan, not the plan from the picture.

Result

90% instead of 50% Match in dimensions and proportions with the furniture the client receives. The old route — designer first, plan second — gave about half. The figure applies to built-in furniture; free-standing items are not covered. A kitchen of 378 parts in three views renders in about six minutes on a laptop.

Why the model is kept away from the geometry

The pipeline has two halves, and that split is the whole point.

Blender computes the truth. The export becomes a Cycles scene with real dimensions, the real layout and the chosen boards. At this stage nobody is trying to make it pretty.

The generative model makes the photograph. The finished render goes to FLUX.2, which repaints it into a photo and dresses the room with plants and textiles.

The split is not aesthetic but forced: the API offers only a prompt and reference images. No masks, no denoising strength, no structural control — and the depth and canny endpoints were closed in October 2025. There is nothing to stop the model quietly stretching a cabinet. So it is allowed to repaint only geometry that is already correct.

One seed per order

The most expensive finding turned out to be one line long. With independent generation seeds, two views of the same kitchen diverged across four surfaces at once: worktop, splashback, fridge and floor all looked different. A shared seed for the whole order — and both views matched on all four.

This has a product consequence more important than the finding itself: there can be no «re-generate just this view» button. A recompute always covers the whole set, otherwise it stops being one kitchen.

The check was one comparison per condition, so this is an observation rather than a proof. We record the seed of every order so that any result can be reproduced and taken apart.