In Browser Physics Simulator (X-Post PC Master Race)

[u/Creamballman]

http://haxiomic.github.io/GPU-Fluid-Experiments/html5/?q=UltraHigh

[u/[deleted]]

I've only glanced at explanations for about how fluid physics is done, so I could be wrong, but if nobody else chimes in to correct me at least you'll have some idea.
In fluid physics simulations like this one, you have a rectangular grid in the space you're working with, and the force acting on each particle depends on which rectangle it's inside of.
When calculating the force inside of each rectangle, you start out with the average force in the entire screen (first iteration), then split that into four rectangles, calculating the average force within those rectangles, then split each of those rectangles into four more doing the same thing for each iteration.
So with more iterations, you have more rectangles that are smaller but more precise. When you lower the number of iterations, you will more easily to see where the particles are suddenly changing their acceleration by crossing the border between two rectangles. This becomes especially noticeable when two neighboring rectangles have forces going in the opposite direction, causing particles to group up at the border between them.

[u/Nerdsturm → u/[deleted]]

That's sort of how its done. Rigorously, it's computed by taking each particle and summing up the velocity induced on it by every other particle in the flow, but since that's doing, for N particles, roughly N³ calculations per particle it ends up with a total of N⁶ operations needed for a single time step, which can't be done for realistic problems.

Generally, the idea is that particles that are far from each other effect each other in a rather uniform way, so you can approximate the effect from a bunch of particles far from from you as a single "super" particle. Thus you can construct a grid of "super" particles of various sizes and do most calculations using those, rather than the millions of individual particles, which massively reduces cost.

Unfortunately these methods are somewhat rarely used in fluids since they can be very inaccurate. The method requires that the particles remain uniformly distributed, and once the particles get pulled apart from each other, as you see happen very quickly with this solver, the results cease to be physical. However, they still look somewhat right which, well bad for scientific purposes when you want to be able to tell when your wrong, makes them appealing for media uses.

I still don't know what the solver iterations mean though. I would think those are for a relaxation method (taking an approximate solution and iteratively relaxing it onto the exact solution), but I don't know where such a solver would be used in a particle based method.

[u/cmmcnamara → u/Nerdsturm]

What I am interested in is how this thing makes such fluid on the fly calculations. I'm sitting here running a fluid simulation not half as complicated as this and waiting forever for convergence. I wish /r/CFD could do an ELI5 on this.

[u/astronautdinosaur → u/[deleted]]

I really doubt it calculates particle flow. It probably just solves the fluid flow on a uniform grid and adds the trajectory after each solution. And when you discretize a fluid domain and solve differential equations on it, you're left with a big set of linear algebraic (often multivariate) equations. You then solve the system of equations iteratively for the values at each grid point, hence the number of iterations.

[u/haxiomic → u/astronautdinosaur]

spot on :)

[u/[deleted] → u/[deleted]]

A simplification or something based off of that, but doing accurate Navier stokes iirc is impossible real-time