Hacker News new | past | comments | ask | show | jobs | submit login
WebGL Fluid Simulation (paveldogreat.github.io)
868 points by joshdance 30 days ago | hide | past | web | favorite | 101 comments



I tried this on my mobile phone, expecting it to not work properly, but everything was super-smooth. Impressive.


Mobile phones have quite powerful GPUs even on the lower end devices. Many are based on ARM's Mali GPU series that has up to 28 shader cores. That's not going to compete with the hundreds of cores than a PC GPU has available but it's more than enough for a straightforward (but still very impressive) WebGL shader like the one in the link.


Not on my older phone which lacks OpenGL ES 3.2, usually needed by these webgl fluid sims (they compute by rendering to a float texture).

A simpler one, and without fancy lighting, but with a code walkthrough/tute http://jamie-wong.com/2016/08/05/webgl-fluid-simulation/ ... also doesn't work on my phone. :(


I know right. So then I tried multi touch on my iPhone. Five fingers smooth as can be..


:O THE MULTITOUCH! Man am I ever a sucker for a good multi touch demo.


Regardless of the demo, I’m just so amused how fluently it works. Then you add the demo. Wow. (Insert mind blown gif here)


Yes, works beautifully on mobile! Even supports multi-touch. Awesome job.


Holy heck it does. Just tried five fingers and it worked flawlessly.


There's even an app based on the experiment: https://itunes.apple.com/us/app/fluid-simulation/id144312499...



You can crank up both resolutions to maximum on a recent mobile device and expect 60 FPS. That plus all 10 fingers on an iPad looks pretty cool.


Indeed! I was doing a five finger control too and made quite a whirlwind of light.


Amazing project!

For what it's worth, the Github page references to the GPU Gems book for this effect: http://developer.download.nvidia.com/books/HTML/gpugems/gpug...


Every so often you get an app that shows you just how fast modern hardware is when unencumbered by the usual endless layers of bloat and inefficiency.


To be fair this shader was published in GPU Gems 15 years ago (2004). Back in the days of the GeForce 6 and Windows XP. Though the fact that it now fits in your pocket is cool.


That is actually amazing. I mean the fact about 2004.


Yes, we were such illiterate savages back then.


Ironically OpenGL programming is also often slammed here for being overly verbose and complicated


As far as I understand it is criticized as having too much hidden state, for a simple (but impressive) application like this it would not be an issue.


To be fair, 2D fluid simulation represents a small quantity of very parallelisable math statements.


Re: everyone impressed by how fluid it is with multitouch: The number of touch points doesn't affect the performance of a grid simulation. Using 10 fingers just sets high values at more places in the initial grid. The effort to solve each time step is the same after that. The computational effort scales with the resolution, not the boundary conditions/input.


I'm impressed it handles multitouch without scrolling or zooming the page. Many similar demos I've tried suffer from such issues.


That's true. The actual UI implementation of the multitouch is great.


It could be in part because the default settings don't let you see the persistent levels of turbulence throughout the entire grid. Set the density to .996 and velocity to 1 and vorticity high and you'll see just how crazy it can get.


Default settings don't really do it justice IMHO. Try these:

Density diffusion: just a hair under 1(visually)

velocity diffusion: 0.99

pressure: 0.93

vorticity: 5


I also tried high Density Diffusion - loved the slower movement and that made me think - only if there was a way to export that to a something like a moving wallpaper that I could set to my Ubuntu desktop.

Also, just setting Density Diffusion to 1 and leaving makes the movement slow enough to be able to screenshot nice wallpapers.


Remember Microsoft's old "Active Desktop"?

It was like a webpage as a wall paper.

Maybe ahead of it's time as it crashed constantly...


I do. Coming from Win 3.1 and due to restrictions on internet connectivity in our office then, at first I had no idea how to use it and thought it was some advanced feature.


Yes and E̶l̶e̶c̶t̶r̶o̶n̶ apps that thankfully died, sorry packaged HTM apps.


Wow, wasn't expecting your settings to be that much different. But love the slower feeling. thanks


for trippiness try Density diffusion: just a hair under 1(visually) velocity diffusion: 0.99 pressure: 0.2 vorticity: 30


Impressive demo! WebGL is an awesome piece of tech that only now starts to be largely adopted. I mean, it gives you access to 100s of cores to compute, run, display stuff :).

Too bad Apple doesn't move forward with WebGL2 and Google splits the community in 2 with webgpu.


But WebGPU is more like Vulkan (in concepts) and WebGL is pretty much a 1-to-1 port of OpenGL.

It's not splitting the community. They needed a new modern API like what people behind Vulkan did.


95% of the current games use OpenGL / DirectX 11 over Vulkan/ DirectX 12. Vulkan seems to be a nice to have with lots of potential in my opinion. I have yet to find a killer use case for Vulkan, on the web in particular.

With WebGL, in my current projects, the limiting factors are the network, javascript and RAM more than the opengl driver overhead...Maybe the reason behind it is to find common grounds with Apple and supports several investment around Stadia's core technologies?


You are missing NVN, GX2, libGNM and libGCN there, as OpenGL isn't a thing on consoles.


WebGL is kind of OpenGL ES 2.0 and 3.0 subset port, not 1-to-1.

And OpenGL ES is already at 3.2.


Apple has never embraced gaming in any serious way


VRML, QuickTime, ActiveX and Flash did it first.

WebGL while impressive, still fails to keep up with what native 3D APIs are capable of.


Reminds me of those cool visualisations that Winamp had, think they were called Milkdrop?


There is also the open source reimplementation of Milkdrop called projectM, which might be of interest to you.

https://github.com/projectM-visualizer/projectm


Indeed:

http://www.geisswerks.com/milkdrop/

Ryan Geiss' website has some other cool stuff he's worked on:

http://www.geisswerks.com


I’ve once tried to port AVS to GPU: https://github.com/Const-me/vis_avs_dx Already runs ~half of built-in presets.

If I’ll have time for that, maybe I should add custom D3D-specific effects there that weren’t there in the original version. Fluid simulation is one of them. BTW it’s easier to implement with compute shaders. WebGL only support them on Chrome/Chromium and only on desktops, that’s why OP used some trickery with fragment shaders instead.


Here is the "main loop" for the simulation: https://github.com/PavelDoGreat/WebGL-Fluid-Simulation/blob/...

I don't know enough about fluid dynamics to be the judge, but it seems like the engine is using genuine (2D) physics and it's not just "toy physics." Could someone who knows fluid mechanics comment on this?


Sure. It's a correct implementation of the projection method [1] for solving the 2D incompressible Navier-Stokes equations, so it is in fact using genuine physics. In terms of physical accuracy, there are some caveats - it's using the Jacobi method (chosen for its simplicity) to iteratively solve the diffusion and pressure Poisson equations, so the accuracy will be determined by how many iterations you're willing to do. That approach won't scale to larger systems. There are also some limitations from the choice of collocated (as opposed to staggered) grids and the approximations used for the boundary conditions. Nevertheless, for a small 2D simulation, you can get physically accurate results as long as you use enough Jacobi iterations and have a sufficiently fine grid.

[1] https://en.wikipedia.org/wiki/Projection_method_(fluid_dynam...


Also it uses backward differencing, it makes it stable at long timesteps. That is great to run fast for visualization, but it is horribly inaccurate (or possibly even plain wrong) if your system has large gradients in flow speed.


Yes, I've found that computer graphics focused fluid simulations frequently choose stability over physical accuracy. These choices also result in unphysically high numerical viscosity. (I didn't check what finite difference stencil or finite volume scheme the code uses, though I presume it's a lower order accurate one that probably has a fair amount of numerical viscosity.) In principle if you reduce the grid spacing and time step it will converge provided the software doesn't use any tricks like approximate square roots, etc.

The numerical methods for solving the PDEs that computer graphics folks use would surely be considered primitive by someone who develops engineering computational fluid dynamics softwares.


> I didn't check what finite difference stencil or finite volume scheme the code uses, though I presume it's a lower order accurate one that probably has a fair amount of numerical viscosity.

It's just the basic second order central difference. It also uses a first order approximation to the Dirichlet and Neumann boundaries, so that additional error will diffuse throughout the simulation region. It doesn't use any approximation tricks for square roots etc., so given appropriate floating point semantics (as a physicist I have no clue what the shader language specifies there) you can still get realistic and accurate results by reducing the spatial and time steps, which is easily doable for a small 2D simulation on modern GPUs.

Ultimately, though, all the basic "best practices" for simulations of this kind - staggered grids, higher order derivative approximations, etc. - aren't very complicated and are well described in any CFD textbook. What really makes engineering CFD software complicated are things like handling complex geometries with dynamically refined meshes, efficiently solving the resulting linear equation systems at scale and coupling the fluid dynamics to other physical phenomena while retaining numerical stability and accuracy.


Don't get me wrong: Doing all the approximations to get a fast, visually appealing animation is perfect for what this demo aims to do.

Fluid simulations for science or engineering (think airflow around the next Boeing design or simulations of planet formation) are still very hard. And that is not because physicists are stupid, bad at coding or easily replaced with machine learning.


Sorry, I was unclear. I agree that the demo does what it intended to do. I was just listing a few additional reasons to believe it may not be physically accurate as-is. I know from previous discussions on HN that many readers are interested in this.


Totally good idea to do that. I just want other readers to be aware for what applications that is useful and for what applications other techniques are more appropriate.


I clicked this thinking "yet another fluid simulation" but this is super cool. Played with every single parameter ;) Pausing, then drawing, then unpausing was a surprisingly pleasant effect.


Really beautiful !

To have it full screen on mobile, you can use the "add to home screen" feature of your browser"


The webpage links to an app which allows this to be your wallpaper and lock screen (on Android for sure). Absolutely awesome!


This is my favorite app on my iPhone. Better than a fidget spinner.


Your comment inspired me to install the iphone app. My kids (2 and 4) are going to looooove this. Thanks!


Cranking all the values up to max makes for quite the show.


If you guys like this, you'll like Verve (fluid dynamics painting tool):

https://www.taron.de/verve/verve_download.html


Such a nice demo! I'm amazed by how smooth it's running on my phone. Even if we already have seen similar shaders back in 2004, this is running on the web, available to everyone, with no installation.

During my 3rd year at uni I played with webgl1 to create a fake fluid simulation, my demo looks crap nowadays http://jspdown.github.io/mod1/


This works with decent smoothness even on my 8 year old 35 dollar iphone 4s.

I met a fellow at Nasa Glen in the 90s that worked on fluid simulations using an sgi workstation. I don’t remember how long the simulations took to process but had to be several minutes per frame. I do remember those workstations cost well over 30 grand at the time.


Thought the tails/vortex look like curl noise. And after looking at the source, sure enough they are


Colors are amazing. It's weird it triggered smell and feelings from 15-20 years old memories.


WOW! Not only is it FAST, it does multi-touch too! Successfully did 4 fingers already, although saw it somewhat slow down but not much.

On a beefy system this could probably handle the full 10 point touch no problem!

I am doing this on a desktop (Arch + Gnome 3) with an Acer touch display.

Well done!


I'd be a little surprised if multittouch affected performance significantly. It's probably simulating and rendering every cell every frame regardless. I couldn't notice a slowdown on my phone with five fingers.


Woah, you're right. I just tried it on my Pixelbook screen (keep forgetting it's touch screen), and it handling as many fingers as I could give it (all 10) with no lag.


I'm guessing the number of inputs doesn't really influence simulation speed since the shader runs each frame for each pixel anyway. When touching the screen, some pixels are changed to hot/colored, but that doesn't really change the amount of computation needed to simulate the whole screen.


10 fingers on ipad pro, no slow down.


This is so nice! The pause box makes the whole demo flex really well. Impressive work


Although this is just a demo, it's really fun to use! Relaxing, even! Well done.


Super cool on iPad

It can track 10 fingers at once did not even know the iPad could do that.


Does it go to 11?


That's not a finger.


RIP Plasma Pong. Was bought by acclaim but was never sold..


Wow so cool. Any summary on how the algorithm works roughly?


The repo refers to this article: http://developer.download.nvidia.com/books/HTML/gpugems/gpug...

Looks like it's standard Navier-Stokes.


Not quite standard. The trick is to use backward differencing in time, to make it unconditionally stable even for longer time steps. Also the Poisson equation to get the pressure is only solved approximately by doing Jacobi iterations until the solution is "good enough". And of course it is limited to 2d and the incompressible limit.


If it's based on that, it's essentially an implementation of Jos Stam's "stable fluids" which actually uses some tricks to get plausible results. http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/...


this keeps reappearing, but it never gets old

just a random recommendation: I love to connect this from a laptop to a TV screen, connect a wireless/long cable mouse, and play it with my cousins / little kids. it's a one time trick, but they always love it. (you can do the same with other programs / simulations, just enhancing the experience a little bit can do wonders)


Super cool on Firefox on Moto X4! Five fingers!


Whoa this is jaw dropping on mobile. Try typing in a density diffusion of .996 and setting velocity diffusion to 1


Add a fullscreen mode and I think this will keep my toddler entertained on occasion.


Nicely done. It's impressive how fluid and detailed the graphics are!


Here's a React version of the above simulation: https://github.com/transitive-bullshit/react-fluid-animation


Impressive! Works well even with 10 fingers on my touch screen.


Just makes you appreciate how impressive modern hardware is.


Wow, this is so... fluid! Even on a mobile device.


Does not seem to work on Firefox 66.0.5


Fine for me, same exact version, Win7. Gorgeous and silky smooth at 1920x1080 on my 8-year-old laptop's crappy Intel GPU.

This is really beautiful work.


Works just fine on 66.0.5 for me (On MacOS).


Firefox 66.0.5 on Ubuntu checking in.


It depends on google analytics and will break unless ga() is defined. Most adblockers spoof it for you, but if you're only blocking requests to trackers the javascript will fail. (eg pi-hole, uMatrix)


Works fine with Firefox 66.0.5 and Win10. Maybe some custom settings in about:config are interfering?


Screenshot capture fails, the download fails with network error. No errors are reported in console or the network tab.


My cat loves this on the iPad


I could do this all day....


this is gorgeous!!


I AM A WIZARD


The effects are very slow on chrome v74, but super smooth in FF v66. I suppose that's Electrolysis[1] in action.

[1] https://wiki.mozilla.org/Electrolysis#Overview


It's perfectly fluid on my 74.0.3729.157 (Official Build) (64-bit) set-up.


I'm on Chrome v74, and the effects are buttery smooth, even at max resolution.


Check chrome://gpu


https://pastebin.com/LDMjLWgn

I suspect the nouveau video driver is the culprit.

I'm currently using Ubuntu 18.04




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: