If you add a `uniform vec3 mousePrevFrame` that tracks the previous mouse position, you can get smoother drawing in main() by replacing your distance function in the line `float dist = distance(mouse.xy, gl_FragCoord.xy)` with a custom
First of all, just extrapolating from someone's side/hobby/demo project to all WebGL pages is naive. The effort put into a demo is orders of magnitude less than a real site.
I mean, these kinds of things should work without highly paid devs like googlers. I have seen a lot of WebGL projects on HN and they always have had issues on some recent devices.
The biggest problem with the WebGL compatibility issue is that it is unpredictable. We don't know which devices work until we open the page. Maybe I am expecting too much, but this degree of inconsistency shouldn't happen to hobby projects neither.
I think most of this is just WebGL 1 (AKA OpenGL ES 2) versus WebGL 2 (AKA OpenGL ES 3).
If you restrict yourself to the basic parts of WebGL 1 your app will work almost everywhere, as compatibility is excellent on all recent phones and OSes.
There’s a lot of nice stuff in WebGL 2 (eg float textures, vertex textures) but as soon as you try to use it you either sacrifice compatibility on a bunch of devices, or you have to check for various extensions to try to figure out what’s going to work, and try to fall back gracefully if possible.
I've never had problems with three.js, which is what most people use for WebGL-powered content.
Are you claiming that there's less effort in coding up a native graphics program that works across all platforms?
Certainly native has the edge on performance (WebGPU will shorten the gap a bit), but on ease of multi-device compatability? I could be convinced, but it seems hard to believe. The whole idea of the browser (these days) is to make cross-platform stuff easier to develop.
1. Flash is not a standard. Flash is developed by a single company. There could not be any compatibility issues because of that. Web is moving to that direction with Chromium engine being used everywhere, but it's not there yet.
2. Flash is relatively high-level API when it comes to graphics. Shaders are low level and while they should work everywhere, I guess, one could still run into compatibility issues between different video adapters.
That said, cross platform compatibility is always going to be hard. I'm still amazed that Adobe let that platform die. It has taken so long and so much effort to recover equivalent functionality, and in some cases we are still lagging what Flash could do.
Amazing! Something I have learned from similar experiments in the past - instead of drawing a circle each frame, try drawing a (rounded) line between the current frame's cursor location and the previous frame's cursor location. Cursor movement looks much smoother that way.
It's well done, though anyone who regularly browses Shadertoy or similar websites has probably been desensitized to old-school (yes, old school!) liquid demos compared to what the cool kids do these days... but well done nonetheless!
Looks neat. Doesn't seem to work with my Razer Blade Stealth touchscreen though (touching to move mouse doesn't work like normal, touchpad has to be what moves it). Would be super cool with multitouch support.
I also get a flickery mess, on Linux + Firefox 81 with Haswell Intel Graphics. I suspect that there is some sort of uninitialised buffer/variable somewhere, and different drivers handle it differently.
It has a bit of delay. And that's why I prefer native vs web applications when performance and end user experience is paramount. This effect is implemented in ZBrush for decades now, on lesser hardware with no delay between mouse movements. Currently web applications just reinvent the wheel from old desktop ones.
The delay (or more accurately smoothing) of the mouse position is a hack to make the mouse trail look more like a streak rather than repetitive little blobs. I call it a hack because the proper solution would be to have a line-shaped source that extends between the last and current mouse positions. Native might allow you to marginally pump up the FPS, but that wouldn't save you from the little blobs.
(edit: just to be clear, I'm not the author but this issue is common enough)
I think the experience might benefit from showing the mouse pointer, or some other cursor that actually tracks your mouse and shows the blobs current "target". You will undoubtably lose something in the process, but I think it would be worth the tradeoff.
Right now, it feels difficult to control. I can never quite get the blob to do what I want, which is crucial for an interactive experience.
response for @pierrec / @scandinavian / @t0astbread:
If you move the mouse slowly there is little to no delay between the movement and the "bubbles". Moving faster and faster and the "bubbles" are falling behind more and more. This effect is even more evident when moving at the same speed in straight lines vs moving in circular motion. Which tells me there is a performance drop.
This does not happen at all in ZBrush. Do try it, it has this effect implemented for decades. I remember playing with it in 2003 on a P3 350 MHz / Win 2k as OS. There was absolutely no "loss" of mouse movements nor "bubbles" skipped as it is the case here.
For me, it's solidly H. R. Giger - something about the juxtaposition of large smoothly shaded areas and messes of intricate detail, plus the moody monochromatism, and the fact that it has come straight from hell.