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.
b, ut if it works is good!