Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGL Fluid Simulation

paveldogreat.github.io

Post reply on HN
Print view View original

91–100 of 106 posts

Re: WebGL Fluid Simulation

#91

Post by petschge »

keldaris wrote: post #78
ivansavz wrote: post #51

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…

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.

Re: WebGL Fluid Simulation

#92

Post by pjmlp »

kbumsik wrote: post #76
batmansmk wrote: post #46

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.

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.

Re: WebGL Fluid Simulation

#93

Post by batmansmk »

kbumsik wrote: post #76
batmansmk wrote: post #46

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?

Re: WebGL Fluid Simulation

#94

Post by btrettel »

petschge wrote: post #91
keldaris wrote: post #78

Earlier quoted context omitted.

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…

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.

Re: WebGL Fluid Simulation

#95

Post by petschge »

btrettel wrote: post #94
petschge wrote: post #91

Earlier quoted context omitted.

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…

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.

Re: WebGL Fluid Simulation

#96

Post by btrettel »

petschge wrote: post #95
btrettel wrote: post #94

Earlier quoted context omitted.

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…

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.

Re: WebGL Fluid Simulation

#97

Post by petschge »

btrettel wrote: post #96
petschge wrote: post #95

Earlier quoted context omitted.

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.

Re: WebGL Fluid Simulation

#100

Post by keldaris »

btrettel wrote: post #94
petschge wrote: post #91

Earlier quoted context omitted.

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…

> 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.

Post reply on HN