A 3D landing pageyou can actually play.

A scroll-driven hero proves you can time an animation. It does not prove you can hold 60 frames a second while a skinned character, a rigged enemy, instanced foliage and a physics-ish grapple all run at once. A game does, because a game breaks loudly the moment the frame budget slips — and because a visitor stays on it long enough to notice.

The commercial point is narrower than “we do WebGL”. Every technique in here maps onto something a merchant actually asks for: a configurator that loads a compressed model in under a second, a product scene that stays interactive on a mid-range phone, a landing page whose motion is driven by state rather than hand-written scroll math. BloomBound is the stress test for all of those at once.

The world reads as much bigger than it is. Seven GLBs from the Kenney Nature Kit — three flowers, an oak, a mushroom cluster, a water lily and a stone bridge — are instanced with InstancedMesh across four named districts: Blossom Avenue, the Temple of the One Eye, the Ancient Rose Forest and the HoaHwa Garden. Instancing is the whole trick: hundreds of visible plants cost a handful of draw calls.

Everything that is not a plant is built in code — the houses, the round-columned temple, the flower arches, the lake and fountain, the windmill, the butterflies, the drifting petals, the launch pads and the billboards. That keeps the asset budget at nine files while the scene still has somewhere to go.

The two characters are the only heavy downloads. The player is the CC0 KayKit Rogue, 3.6 MB with embedded textures, 6 skinned meshes and 76 animation clips, of which the game blends 5. Unused equipment is hidden at load rather than shipped as a separate model.

There is no good CC0 one-eyed giant with a walk cycle. What exists is Eldritch Grim's Giant Mutant — a two-eyed body with a 22-bone rig and no animation we could use. So the body was voxel-remeshed into a single continuous surface, smoothed, and decimated to 9,002 vertices and 18,000 triangles, with skin weights transferred onto the new mesh. The shipped file is 552 KB.

The eye, mouth, floral crown and linen accessories are added in Three.js at load time, not baked into the asset, which is why none of the original textures or clips are redistributed. Every movement — breathing, looking, blinking, walking, running, roaring, the attack wind-up, the stomp, the swipe, the stagger and the collapse — is authored in code against those 22 bones.

That last part is the reusable lesson. Buying a rigged model and animating it yourself is dramatically cheaper than commissioning animation, and it keeps the licence clean. The remesh pipeline is committed alongside the game so the asset can be rebuilt rather than trusted.

The site is a Next.js app exported to static files. The game is a Vite app. Rather than port the game to React or wrap it in an iframe, Vite builds with `base: '/apps/bloombound/'` straight into the Next.js `public/` tree, so `next build` copies it into the export verbatim and the game ships through the site's existing rsync deploy with no second pipeline.

Two things had to be right for that to work. Every runtime asset path — the three GLB loaders — has to resolve through `import.meta.env.BASE_URL` instead of a leading slash, or the models 404 one directory up. And the link in the site header has to be a plain anchor rather than `next/link`: a client-side navigation to a path the static export's router has never heard of resolves to a 404 instead of loading the game.

The payoff is that the game is a first-class page of the site — crawlable, linkable, deployed by the same command as everything else — rather than a demo parked on a subdomain.

The whole build is 6.2 MB, and the honest headline number is the Three.js core: 563 KB raw, 143 KB gzipped, before any game code. The game's own logic is 69 KB raw and 27 KB gzipped, which tells you where the weight in any 3D project really lives — the engine, not your code.

That is a fair price for a destination someone chose to visit. It would be indefensible on a storefront homepage, and we would not ship it there. The useful version of this work on a commercial site is one interactive scene loaded on demand, not a whole engine in the critical path.

The verification is the part we would repeat on any client project: 96 automated browser checks — 47 on gameplay and UI, 40 on the world, models and enemy AI, 9 on mouse and fullscreen input — all run against the real production build at its real URL, with console errors treated as failures. Mobile is covered by 390 px Chrome touch emulation, which is a genuine check of layout and touch controls and is not the same as a physical device.

BloomBound has a fourth realm. Blossom Crown is a painterly dark-fantasy throne hall — navy and gold banners, coral-pink and violet fractal blossom trees, crows circling a castle under a misty pink-grey sky — art-directed from three concept paintings by our artist team: the throne hall itself, a knight march with a giant red sword, and a magenta holographic HUD. The whole scene renders at roughly 256,000 triangles.

The realm is procedural where it counts. Twenty-five road paths are planned around the castle with a 4 m baked avoidance mask, and that planning step went from about 15 seconds to 151 ms — the entire realm builds in around 0.4 seconds. Twenty-six vehicles (carriages, carts, cavalry) travel those roads through instanced scenery: 48 blossom trees, 140 pines, 167 banners, 334 lamps and 60 crows.

The new gameplay is an escort mission: guard a carriage along the road to the castle while giants smash the traffic underfoot — and hitting a giant's eye counts. A painterly post-processing pass (toon ramps, outlines, bloom) ties the realm back to the concept art. Behind it sits a proper asset pipeline: headless Blender 5.2 scripts to optimize, stylize and preview, plus a Tripo 3D v3 API client for generating props.

The build itself is the other story: the work was split across several AI coding agents, each in its own git worktree — the same setup documented in our Notch Agent Train case study. Blossom Crown was built and tested locally on 29 October 2026 and is now rolling out; the figures in the stats above remain the September measurements of the original three chapters until we re-measure.