How We Built the 3D Lotus on bloomify.ca

The lotus on bloomify.ca is a 3D scroll animation: a Three.js model rendered in the browser and driven entirely by scroll with GSAP ScrollTrigger, so every frame you see is a direct result of how far you have scrolled. Scroll down and it opens, bursts into pollen, and later rebuilds itself as our logo. Scroll back up and all of it plays in reverse.

This is the build log for that 3D scroll animation: what it is made of, how it stays fast, and what broke once it met real phones.

What is the 3D lotus made of?

The lotus is a single GLB model with about 47,000 triangles, rendered with Three.js. The geometry was never the heavy part. The first version of the file was 8.94MB, and 7.42MB of that was textures: a 4.9MB normal map and two more images, all 2048 pixels wide.

We re-encoded the textures at the same 2048 resolution and brought the model to 3.03MB. A smaller 1024-pixel version came in at 2.18MB, but on a high-density phone screen it measured 3.7 times further from the original, and you could see it in the petals. We kept the sharper one.

How does a 3D scroll animation stay smooth?

A 3D scroll animation stays smooth when nothing in it runs on a timer. On bloomify.ca each section is pinned in place with GSAP ScrollTrigger while you scroll through it, and everything on screen is calculated from that section’s progress, from 0 at its start to 1 at its end.

• One owner at a time. All the sections share one canvas. Exactly one section is allowed to draw on it in any frame, so two animations never fight over the same pixels.
• A smoothed scroll value. Raw scroll jumps with every wheel notch. Each section eases toward the real position instead, which removes the stutter without adding lag you can feel.
• Particles sized to the device. The “One studio” sentence is drawn by 60,000 particles on desktop and 18,000 on phones.
• Dust in batches. The 2,200 motes that build our logo at the end are drawn in 14 brightness groups. Styling each mote one by one cost 21.8ms a frame, over budget for a smooth scroll; batched, it is 14 fills.

How does the loader show the lotus growing?

The loading screen plays 66 frames of the lotus growing from a seed, packed into one image so it loads as a single file. The frames come from two generated clips, each pinned to stills we already had: a seed opening into a bud, then the bud opening into the exact picture the page starts on. The last frame of the loader is the first frame of the site, so there is no jump when it hands over.

Two earlier attempts faded between a few still images. Both looked like petals fading in rather than a flower opening, because there was no real motion in the source to recover.

What made the page load faster?

The homepage went from 10.33MB to 4.43MB. Most of that was the model textures above. One fix was a single missing attribute.

We preloaded the model so the download starts while the page is still being read. A preload for a file fetched with JavaScript needs the crossorigin attribute to match how the file is requested (see MDN on preload). Without it, Chrome threw the preloaded copy away and downloaded the 3.2MB model a second time. With it, the model downloads once, starting 121ms into the page load instead of 849ms.

What broke on real phones?

Everything looked right in automated tests. Three problems only showed up in screen recordings from a real phone.

• Pace. A thumb flick covers far more of a section than a mouse wheel does, so the story ran by too fast. The pinned sections now scroll longer on phones, and the parts you read, like our process steps, get the most room.
• A flash on resize. A phone’s address bar changes the screen height as you scroll. Resizing the shared canvas repainted the last frame the hero drew, so the hero’s light flashed over a completely different section. The resize now only resizes, and whichever section owns the canvas repaints it.
• Frozen frames on a fast flick. On a hard flick, a transition could switch the next section’s drawing off after that section had switched it on. The section now switches its own drawing on every frame it owns the screen.

The lesson we took from it: test a scroll site on a phone, with real flicks, and record it.

Does a 3D scroll animation hurt SEO or accessibility?

It does not have to. The headings and text on bloomify.ca are real HTML, not pictures inside the canvas, so search engines read the page normally. Visitors who ask their device to reduce motion get a still version of every section, which follows the WCAG guidance on motion from interactions.

If you want a site that moves like this and still loads fast, see the work we have shipped, read about our website design, or book a free 15-minute call.