Engineering // Build Log
420,000 particles, about 60 frames a second, computed live on the graphics card in a browser tab. No video, no plugin, no page builder. See it run, or read why it was hard.
The hero is a stock animation from a page builder or a forty-dollar template, dressed up with a gradient. It loads slow, it looks like ten thousand other sites, and it proves nothing about the team behind it.
We sell hand-coded sites. So our own homepage had to survive being read by an engineer, not just a client. The page is the proof, not the claim.
420,000 points are handed to the graphics card. Every frame, the card decides where each one sits, projects it, and paints it. The Meridian15 wordmark is not a model or a video. It is those points pulled into the shape of the letters and let go again.
This class of engine is effectively absent from production websites. The technique lives in research demos and a few game engines, almost never on a shipped commercial site. If a competitor could pull it off a template, it would not have been worth writing.
The usual way to draw a particle in a browser is a tiny textured square, one per point. At a few thousand it is fine. At hundreds of thousands it falls apart: the same pixels get painted over and over, the card burns its entire budget on the overlap, and the field smears into mush. That ceiling is why most agency particle work tops out as a soft background, never a sharp, readable mark.
We do not draw it that way. The wordmark stays crisp and legible at a scale where the ordinary approach would have collapsed into noise, and it holds that frame rate while the physics keeps running underneath it.
The method behind this lives in graphics research papers and a handful of game engines. On a shipped commercial website it is effectively nonexistent. We went looking. That gap is the entire reason the work was worth doing.
None of the difficulty is in making it look good once. It is in making it hold 60 frames a second under limits that do not move.
The frame budget is spent before a single pixel hits the screen, so the math per point has to be brutally cheap.
It cannot block, so it cannot occlude, which meant depth had to be earned without putting one thing in front of another.
Nothing here could be checked by a script. Every frame was judged on a real device, by eye, against the number.
One pass we tried cost 35 frames a second for a gain nobody could point to, so it came out and the number went back up. Three of the approaches we wanted most turned out to be impossible on this architecture, and we proved that before we spent a week building them.
Every effect answered one question or it came out: does this make the page better at its job, or just busier.
Fast, because we know where every millisecond goes and we spend them on purpose. Yours, because we refused the template paths, so the result cannot be bought off a shelf or faked with a plugin. Honest, because we delete our own work the moment the numbers say it is not earning its cost.
If we will write a GPU engine for our own homepage, picture that standard on yours.
Ready to build?
We hand-code sites to the same standard we hold our own to. Tell us what yours needs to do.