Cake Render Bake-Off

Part one

Where the last build landed

The April build (franticc-backup/cake/index.html) is roughly 2,000 lines of hand-tuned canvas code that produce exactly one cake. Seen fresh, the problem isn't vague "cartoon-ness" — it's five specific, fixable-sounding-but-structural things:

• Outlines force the clipart reading. Every stripe, drip and dollop carries a dark stroke. Dimensional cartoon art (Pixar, or any modern 3D-cute style) has no outlines — light does that work.
• The perspective contradicts itself. Elliptical tops say "camera looking down 40°"; dead-straight sides say "camera at table height." The eye can't fuse it into an object.
• No shared light source. Each element carries its own baked-in highlight, so nothing sits in one world.
• The drip reads as a scalloped collar — a uniform belt with a wavy hem, not liquid with weight and gloss.
• Embedded texture reads as pattern. Grid-distributed batter bits become polka dots.

The deeper structural issue: in this approach every new decoration type is another few hundred lines of bespoke drawing code. The marginal cost of growing the decoration library is enormous — and that library is the product.

Part two

Same cake, five ways

To separate "the medium can't do it" from "we executed it badly," I rebuilt the same cake spec — cream striped tiers, pastel-green drip, piped pink dollops, cherries — in four other technologies. Every image below was produced today, from scratch, in a few hours total.

↻ drag to spin — this one is live

Round two · 25 Aug 2026, evening

Pushing Three.js toward texture and realism

Fair critiques of round one: the Three.js render was too bright and flat to judge, Zdog's shapes are monochromatic by nature, and nothing showed texture. Round two is the same technology with better craft — a proper three-light rig (warm key, cool rim, low fill), procedural bump maps painted onto canvas at runtime (palette-knife streaks for buttercream, fine crumb noise for sponge), restrained reflections, instanced sprinkles, and a glossy-ganache variant. Still ~350 lines. Still no Blender, no downloaded textures, no post-processing — this remains the floor of what the approach produces, not its ceiling.

The realism toolkit — what closes the remaining gap

These renders are procedural primitives. Production quality comes from a known ladder, each rung cheap and additive:

• 1 · Blender-authored assets with baked textures. Model each tier finish and decoration once in Blender (where sculpting frosting swirls is easy), bake lighting detail into textures, export glTF. This is how BakerInbox and every product configurator gets its polish — the asset is art once, then free at every angle and color forever.
• 2 · A real studio HDRI instead of the synthetic room environment — instant food-photography reflections. Free ones at polyhaven.com.
• 3 · Matcap materials — an entire lighting setup baked into one small image; the cheapest route to "soft clay-render cute," very hard to make look bad.
• 4 · Subsurface-style frosting via three.js transmission/sheen — the slight translucency that makes icing read as sugar instead of plastic. Glaze and jelly use the same knobs.
• 5 · Contact shadows and baked ambient occlusion (drei's ContactShadows / AccumulativeShadows) — grounding, weight, the "sits on the table" feel.
• 6 · Instancing for the small stuff — thousands of sprinkles, pearls, or crumbs at 60fps (the sprinkles above are one instanced mesh).
• 7 · Decals for writing — piped text rendered to a canvas texture and projected onto the tier surface, curving with it.
• 8 · Gaussian splats for the gallery (the genuinely new trick, 2024+): photograph a partner bakery's real cake with a phone, convert to a 3D splat (Luma, Polycam), and it becomes a photoreal, rotatable model in the browser. Not parametric — wrong for the builder loop — but perfect for template galleries of real cakes next to the configurable cartoon builder.
• 9 · One AI glamour shot at checkout — img2img over a screenshot of the finished WebGL design. Geometry stays anchored, drift is tamed, and the customer gets a photoreal keepsake while the baker gets the exact spec.

The benchmark test · 25 Aug 2026, night

Can it ever look like the Design Connected cake?

The bar Zain set: Design Connected's chocolate icing cake — a professional offline render (V-Ray class). Verdict first: yes, at web resolution — and the wireframe on that very page is the proof. Their own preview shows the model naked: it is a dense hand-sculpted mesh. About 70% of what makes that image delicious is geometry authorship (fat drips sculpted with rounded lips, torn sponge edges, cloth-simmed napkin) and most of the rest is one big soft studio light on good PBR materials. A mesh like that exports to glTF and renders in a phone browser today; nothing in the image is exclusive to an offline renderer except the last few percent of light transport.

The gap, quantified

• Procedural primitives (today's attempt): ~60–70%. Free, instant, fully parametric.
• + Real PBR texture sets (photo-scanned sponge crumb, frosting normal maps — bought or Substance-made): ~80–85%. Days of work.
• + Blender-sculpted geometry with baked maps, studio HDRI: 90–95% at web resolution, live in the browser at 60fps — and the second reference Zain sent (the birthday cake with piped script and candles) is simpler than the Design Connected model: that one is reachable at effectively 100% live. Weeks of asset work for a full library, forever reusable.
• + Server-side Cycles render of the same scene at checkout: 100%. Blender's Cycles is the same class of renderer that produced the benchmark image itself, and it renders the customer's exact configured design in ~30–90 seconds — the photoreal keepsake shot, while the live view stays interactive.

Part three

How far can CSS actually go?

Three different questions hide inside that one:

1 · CSS 3D transforms (preserve-3d). Far enough to amaze on CodePen, not far enough to sell a cake. It composites flat rectangles in space: curved surfaces exist only as seamed prisms, there is no lighting model, and no shadows pass between objects. The best CSS 3D artists alive — Keith Clark, Amit Sheen, Ana Tudor — produce faceted papercraft, and the best pure-CSS 3D cake on record shows gapped panel cylinders and billboard toppings. When a medium's best-ever work sits below your minimum bar, the question is answered.

2 · CSS-styled SVG. Much further — as flat illustration. Fully parametric, crisp at any size, real text support, and the bake-off shows it can be genuinely pretty. But it is a picture, permanently. (Also worth knowing: most famous "CSS cakes," and all of Lynn Fisher's single-div art, are 2D paintings — the community itself routes around CSS 3D for organic objects.)

3 · CSS as a shading toolkit — gradients, ellipses, shadows. This is the same visual algebra the canvas build used, and it fails the same way: pseudo-3D heuristics don't survive contact with glossy, volumetric, organic material like frosting. The failure was the approach, not the canvas element.

Part four

The full option space

Every viable rendering direction, scored for this product: a cartoon-styled builder with tiers, drips, piped borders, free-placed decorations and text, mobile-first, with a growing decoration library.

Part five

What everyone else is doing

Verified today, by loading the actual products (several block bots; those were driven in a real browser and their rendering stack read from the DOM).

At retail scale: it's all flat 2D compositing

Walmart and Sam's Club run the same play with a bespoke 2D canvas compositor (confirmed in-DOM: a single canvas-image element, no 3D libraries): wizard steps, photo-composite preview at a fixed angle. Walmart · Sam's.

Dairy Queen, Baskin-Robbins, Carvel: design galleries, photo upload, form options — static photos or light compositing, no builder canvas at all.

Why they converged here: their SKUs are photographed sheet cakes with edible-print toppers. Photo compositing is cheap per SKU and photoreal. It also means none of them can do what your tool does — arbitrary tiers, drips, free-placed decorations.

True 3D exists — but only baker-facing, never consumer ordering

Also in this tier: ProCake (baker SaaS, 3D quoting), Bakely (native app, 3D wedding-cake visualizer, ~200k users), Cakenote (2D/3D/AI design inside bakery management). Configurator platforms (Zakeke, Threekit) showcase shoes and sofas — no one has claimed food. Open source has nothing serious to build on.

India: catalog only — no visual builder exists

The Indian delivery market — your launch market — runs entirely on catalog + photo-upload. Nobody renders anything.

Combined with the US picture, the strategic read: a consumer-facing 3D cake builder wired to a real order pipeline does not exist anywhere yet. The rendering decision is also a positioning decision.

Part six

The decision framework

Six things actually matter for this product, in this order: does it read as a cake · marginal cost of growing the decoration library · parametric freedom (any size, any color, free placement, text) · mobile reach (share a link, no install) · drag-and-drop fit · one person can build it. Weigh those and the space collapses to a handful of honest branches:

Part seven

If the recommendation is taken

The JSON design schema from the scoping doc stays exactly as it is — it's rendering-agnostic and becomes the single source of truth that the Three.js scene renders from. Concretely:

1. One-week spike: extend today's 200-line PoC into a schema-driven scene — tiers, drip, borders and dollops generated from the JSON, orbit controls, recolor via material swap. This de-risks the whole direction for the cost of a week.
2. Lock the art direction with 3 lighting/material looks (matte pastel, glossy toon, soft-studio) rendered on the same cake — pick one. Optionally mock it in Spline first.
3. Decoration library pipeline: simple decorations stay procedural (primitives, like today's dollops and cherries); complex ones (figurines, florals) become small glTF assets modeled in Blender — each new asset is modeling work once, then free forever, at every angle and color.
4. Drag-and-drop = raycast: pointer ray → tier surface hit → decoration snaps to the surface normal. This is standard, well-documented Three.js territory, and it's better than 2D drag-drop because placement is genuinely on the cake.
5. Text on cake via TextGeometry bent along the tier arc or a decal texture — both first-class, neither possible convincingly in any 2D approach.
6. Performance guardrails for low-end Android: cap pixel ratio at 2, budget draw calls, no post-processing. A one-cake scene is far below what phones handle in games.