This looks really good! Implementing a physically accurate free surface fluid model (Volume-of-Fluid in lattice Boltzmann) was one of the hardest things I've ever done. Literature is full of errors and one particular paper with wrong equations did cost me months. But in the end it was all worth it and I could significantly improve the state-of-the-art method on GPU.
Wow! This is very impressive! I do remember times when I did try to write code to simulate fluid using navier stokes / finite elements in University 20 years ago and it took more than year to make things stable for simple setups.
These tutorials are amazing! Compared to the traditional paper, using videos, interactive demos and code samples really improves the accessibility of physics simulations, which can be a very hard topic to get into. Thank you so much for doing these tutorials Matthias, very inspiring both from a coding and teaching perspective.
Awesome video as always! I'd love to see you cover the shallow water equations for simulating a fluid surface. Can produce some convincing results too!
11 месяцев назад
Awesome simulator. Thank you very much. Greetings from Popayan, Colombia.
I experimented with the project and added a fixed obstacle 90% of the way across the middle of the page and generated water particles above it. The problem I have is the solid obstacle leaks. While most water runs to the end of the obstacle and falls to the lower chamber. a significant fraction falls as 'rain' from the bottom of the obstacle. Is there any easy way to stop the leaks? I think the same is happening with the round obstacle as well.
Great video as always. Is the k*(rho - rho_0) term a standard trick? I don't believe I've seen it before in FLIP solvers. It seems like it wouldn't actually converge in the limit to the zero divergence solution unless all local particle densities converge to the global average particle density. Would you use it like this in practice with fixed k (your code seems to use k = 1) or would you drive k to zero over multiple solver iterations so as to avoid this seemingly non-physical behavior? Thanks!
Very good question. Fighting volume loss in fluid simulation is a difficult problem. Many methods have been proposed. I should have mentioned that mine isn't the final answer. It has the problems at the boundaries for instance as sph or pbf methods have due to the fact that the density is too small there. 10 minutes are too short to discuss this field but maybe I will do a separate tutorial on this interesting subject.
@@TenMinutePhysics But isn't the lower densities at the fluid edges what creates surface tension in real-life fluids? It appears so from the simulations I have implemented over the years.
Nice approach using the same grid, but it doesn't mean you have to ignore the gas cells! I just assume fluid velocity has a larger weight than gas and combine them wherever the fluid goes. Accuracy and speed is always a tradeoff, but it is possible to compromise to keep average error low and give plenty of room to make it very, very fast and highly parallel. For example, boundary condition correction can be quite heretical without sacrificing much visual fidelity, which sounds horrible, but it's a simple as something similar to signed distance field, but in a texture that can be sampled and added to position. I researched all of this and well, I'm no Carmack :D. It all depends on your objective.
Is there any way to combine this with XPBD or use some of the lessons of XPBD together with FLIP? How about combining simulations of solids and fluids? Let's say you want to simulate some boats on top of the ocean, but the boats should have some small swimming pools within themself, and some toy boats in the swimming pool. How would one simulate all of this together knowing what we know about XPBD?
Your explanations are so clear! Can you give us a clue on how to incorporate the effect of forced convection (wind) on the surface of the fluid? Thank you! 🎉🎉❤❤
Why deal with multiple particles in a grid cell, just deal with density, pressure and momentum to get a velocity, then your grid is the resolution and pressure is the color, for air and water separation you can add gravity to each cell and pull down based on density.
Has anyone looked at non-uniform grid update? I'd be interested to see how that breaks down, or if it happens to be useful. Not in terms of scale of the simulation, but like crazy ignoring the speed of sound globally and assuming it matters more locally.
Definitely yes! I will do it for the 3d implementation. It is a bit trickier than using it for neighbor search because you have to handle hash collisions. Two cells must not end up in the same slot.
Vortices persist for a long time in reality in fluids with low viscosity. At airports, planes are forced to wait for the wingtip vortices of the prior departing plane to dissipate sufficiently before they are allowed to takeoff. When a really large plane takes off (which produces strong vortices), this delay can be on the order of minutes before it is safe for another plane to take off.
can you please consider refactoring the older liquid sim tutorial, it works great but I had hard time understanding it... I would suggest separating the code into smaller functions and descriptive variable names
So-called "incompressible" fluids aren't truly incompressible, as they manage to compress themselves under their own weight, more the deeper the fluid pool.
