I wanted to share a production WebGPU project that doesn’t use Three.js — built from scratch with raw WebGPU APIs (with a WebGL2 fallback).
Project: A generative flow-field visualization for a psychotherapy website. The flowing lines represent dynamic patterns and flow, note the transitions too.
I know this is a three.js forum, but I thought the community might appreciate seeing how raw WebGPU implementation compares to what we’re used to with abstractions.
Happy to answer any questions about the wgpu vs gl architecture challenges!
It seems to me that you should work a little more on the performanceof the mobile version…
And I wonder one thing: why a company providing psychological services based in Poland, with information on its website that “we provide services in English and Polish” has the entire website in English… especially in medical services? I made hundreds commercial projects including medical offices, but first time I see this type of scenario in medical environment. Pure curiosity…
On performance: It is a heavy simulation by design. The WebGPU version is optimized (O(N) geometry, instanced rendering) and hits 60fps on modern mobile devices; the WebGL2 fallback is scaled down for older hardware. As a generative visualizer, the goal is to use available device performance rather than minimize it.
On language: An unusual choice for the sector, certainly. The psychotherapy is bilingual, but this site is designed for the international community in Warsaw. A Polish-language site does exist (Centrum Par), though oriented toward couples and relationship work.
Actually, that’s exactly what the production build does—but ‘hiding it’ is just the last resort (Tier D).
The engine currently runs a capability micro-benchmark on boot to assign the device a grade (Tier A-C). Lower tiers automatically downscale internal render resolution (down to 60%), reduce particle counts, and switch to simpler shaders. It only hard-disables the canvas if the device fails to hit a stable 18 FPS in the benchmark or if
prefers-reduced-motion
/
save-data
headers are detected.
The entire physics engine runs in a dedicated Web Worker to ensure the main thread never blocks, regardless of GPU load.
That is too technical for me b, ut if it works is good!
In my case, in most sections, I just hide the canvas with display none, but it depends on the design. Also, when using threejs it is obvious that you are pushing the limit,s and some compromises need to happen.
For me, on mobile, the priority is ensuring users can navigate the page correctly and read the content easily. Any other effects are secondary. This is my strategy, and from what I see, most top agencies work the same way.
One more thing: I checked the performance of your animation, and in my opinion it will work perfectly on all phones that matter, with no issues at all. The performance is really good.
It’s strange… because on iPhone 13 Pro the application behaves quite slowly… but maybe on higher devices it behaves more stable…or maybe my updates issue…
The iPhone 13 is an old phone, also IOS is not that great when ti comes to the canvas and 3D. If we waited for hardware to support everything we want to do, Three.js would never have been born.
FYI, on a 2020 MacBook Air in Chrome, the framerate was much lower than 60fps and interacts with the page like scrolling and clicking perceptibly lagged. I’d be unhappy if I had to use the site to get something done. Since I was there to look at the pretty graphics, though, I had a good time.
This is super interesting but also very odd at the same time. That optimization and assigning tiers seems pretty advanced, but then its “just” creative work, it’s a background that in no way has any impact on how you use the site and find information. Agreed that if this animation were to impact the UX of the website, it would be an overall poor experience.
Curious how come this amount of engineering, using webgpu, no frameworks, assigning tiers controlling the quality vs performance on the fly, went into a fancy background for something that couldnt be any less related to cad, engineering, design etc.
We designed and built this ourselves. We’re the psychotherapists, and the character of the movement mattered. A static background felt inert and a looping video felt mechanical.
We wanted something that doesn’t repeat — that has its own underlying structure, even if that structure isn’t immediately visible. Something that settles into patterns without being told what the pattern should be.
It did take real compute. Organic movement at that density — thousands of lines responding to an invisible field — is expensive. WebGPU made it achievable; the WebGL2 fallback made it accessible.
@alltom — the jank is fixed. Pushed a patch that improves main-thread scheduling. Curious if it’s smoother on the Air.
I don’t know if this is the case, my friend, but usually the reason is money… There is no such thing as a “psychologist”, it is none other than a philosopher who, instead of the concepts of Plato or Plotinus, learned the concepts of Freud or Beck during his psychological studies, and tries to compile these theories on patients. There is much more money in the clinical sectors of mental health, but I am talking about typically clinical ones, for example psychiatry in closed centers, not self-employed, or fictitious, one- or two-partners limited liability companies. In the USA, this approach is profitable, because there are many jaded and embittered wealthy clients who are probably able to pay $1,000 per hour… in Eastern or Central-Eastern Europe, this model is much less popular due to general economic conditions. You see, for example, I am a lawyer and I have been pushing a trolley called IT for over 15 years…
@dubois — Pure curiosity. I treated this as an experiment in self-learning LLMs. Translating the vision into low-level APIs and math was difficult, but a fascinating puzzle to work through.
@Lukasz_Mestales — I’m actually sticking to my clinical practice. The coding was just a personal pursuit to build the site I needed.
b, ut if it works is good!