Hi everyone, I hope you enjoy the video! This is a topic I’ve been wanting to tackle for ages, but have always found a bit intimidating to get started with. So I’m happy to have finally dived in! Let me know if you have any suggestions for improving it, or ideas for future projects. In other news, I’ve recently created a Ko-Fi page where it’s possible to support my work with a one-off contribution (as opposed to the monthly pledges on Patreon). No pressure of course, but if that’s something you’d like and are able to do, you can find the page here ko-fi.com/sebastianlague
I liked the video overall, but the first half was a slog to watch through. I like how acerolla approaches writing a script for that, maybe you could do something similar if there's lots of math involved.
I wrote a reply before but I think it was removed because I included links. Anyway, I highly suggest you look into a fluid simulation method called FLIP (Fluid Implicit Particle), it's also primarily a Lagrangian or particle based method, like SPH, but it achieves improved conservation of quantities like density, and better divergence, by incorporating aspects of finite volume simulations, so it should address many of the issues you've noticed so far with pure SPH being more gas like. Considering you already have the particle code working, building an implementation of FLIP should be fairly easy as most of the changes it requires are calculating some quantities like velocity on a fixed grid rather than at particle locations. FLIP also happens to be one of the default fluid simulation methods used by commercial software such as Houdini, and is available as a very popular Blender addon too, so there's boatloads of work that's gone into optimising, much of which is available for free online. The paper I linked before was titled Flip: A low-dissipation, particle-in-cell method for fluid flow, if you want to learn more.
The near-density trick was something I came up with for my master's thesis 18 years ago, and nobody mentioned that they were using it before today. It took a long time, but it was worth it in the end because I got my name in one of best videos on youtube. Thank you Sebastian.
Maybe the same behaviour can be obtained by including a local minimum to the "interaction" function, so that particles tend to keep a certain distance to their neighbours, not more not less. The constant density would be an emergent property.
A local minimum in the interaction function would also provide a "boiling point": if the energy of the particles is higher than the well depth, the particules break their "bond" and fly with more freedom.
The real insane part of these videos isn’t the coding is the visualisation of the coding at the same time to make it so that non coders can understand clearly, I love these videos
Even people who do code benefit from the beautiful visualizations! It's just an all around great thing to include Kind of like how accessibility features benefit everyone I like this channel a lot 😊
@@MayaPapaya497 Honestly, yeah I wish programming tools had those sorts of visualizations right out of the box. It would make debugging so much easer and less mentally abstract if you could see what was happening.
Honestly making everything as interactive and visualizable as he does is probably as much or more work then just getting the actual equations to work. Though I guess Unity helps a lot with that.
I personally would love to see a "deep dive walkthrough" on you porting this to the GPU. It seems like a great vehicle for introducing a lot of people to GPU programming. You mostly did that part "off screen" here - those details would be hugely interesting, I think.
Sebastian Lague never disappoints. I am astonished by how much a single man can accomplish, and at the same time, how much he can teach others. The 48 minutes that this video lasted felt more like 10 because of how enjoyable and informative it was. I can't wait to see how the finished product will look like. Amazing work!
My problem is that these videos are often a bit too complicated to wrap my mind around, and therefore I have to watch them twice to understand. But that's probably also because I'm not a native speaker. Despite that, this channel is one of the best in explaining.
@@hypertizerWhy? Most of the time his projects are based on well documented techniques. He consistently mentions using papers and reference material - that’s really all you need to implement this stuff.
Its very much possible to do all this coding alone. Just takes patience, skill and persistence. Remember the research was already done in the papers. Not saying it's easy but any decent software engineer should be able to figure out a implementation.
It's so fun to watch these as a physicist! On the one hand, if feels like you get just enough of the physics to follow along with your project, and I, on the other hand, get just enough of the programming to follow along with your video. It's also so cool to see you implementing these ideas. One of my favorite youtube series for sure.
Hello Fellow Physicist! Can you tell me what kind of engine does real life use to simulate Millions and billions of particles (Atoms) and make them interact with each other seamlessly? I mean.. is there even an engine? or is there something else at play here? I've been wondering that for the longest time 😭
@@ashlysherief3850 Gromacs, NAMD, Amber, OpenMM are the most used ones if we're talking about fairly accurate, atomistic, classical simulations. And yes, with multi-gpu or even better, multinode clusters they can simulate even tens or hundreds of million of atoms. They get nowhere near "real time" speed though. Usually it takes months to accurately model big biomolecular systems for just a few tens of microseconds, or a few milliseconds. The problem is that atoms are really really fast, so your simulation step must be about a few femtoseconds. The faster you allow your particles to go, the slower will be the simulation, and with realistic atomist systems you really don't have a choice. BTW they mostly use the leapfrog (Verlet) method for the integration of the equations of motions, which Sebastian mentions, but then they also add stochastic terms in order to sample from the correct distribution of temperatures and pressures.
Developing these prototypes requires a lot of work. The fact you go the extra mile to create visual graphs on what is currently taking place using the Editor itself and no editing tricks is ridiculous, you take a great deal of pride in your work! You are a very smart man!
This is extremely cool! There's something about the combination of particle-based systems and fluid simulations that is fascinating. I ran into a lot of the same problems while trying to implement a particle-based fluid visualization where the underlying simulation is not actually particle based. A lot of the techniques you showed would definitely be applicable to this problem and I'll look into them a bit more. My solution was just giving up on trying to match the density with the particles and instead make the particles act more like dust that is pulled and pushed by the fluid's motion. It works alright but suffers from its own set of issues... Anyway, great video as always!
Thank you! I don't know if I've said before, but your simulations are super impressive and always really fascinating to watch. I'm excited to catch up on the latest videos (now that I've finally finished editing this)!
I did a compsci degree at a decent university many years back... this video is astounding quality and right up there in terms of lecturer quality... and it's free!
Sebastian didn’t end his video with “cheers”. My conclusion is that he’s been kidnapped and had to send a secret message that only we’d understand something was weird about. The chessbots must have finally got him.
This is truly inspiring and the production quality is amazing as well, thank you! I also picked up a few notes for spatial search optimisations I'm excited to try out in my little evolution sandbox simulator
Hi, Huge respect for your work. I am doing right now my thesis in fluid dynamics. I have written already about all math basics. In your video I have not only visualisation but also you share with everyone how to creat code for it. During my studies I was writing the code for movement of the buoy on the waves. I spend lots of time to do it with supervision of my porfesor. I felt like a child id the fog. After your video I have comprehend all knowlege from my Naval Architect studies. Huge respect and thank you thousand times.
I'm not sure it can live up to 10 years of anticipation, but I hope you enjoy it nonetheless :) Definitely a topic I'll be exploring more in the future too.
@@SebastianLague any ideas for future experiments involving AI-related algorithms? I would love watching a revisit to Ecosystem Simulation (probably one of my favourites) with Q-Learning, perhaps
I barely understand anything about how coding works, but your videos are not only relaxing, but somehow make it so easy to understand whats actually happening. Always are great day when a new Coding Adventure releases! Also, cute cat.
Yes, I thought the same. That's likely exactly what it's supposed to do. There's no pressure from the other side, and that affects the distribution of particles.
I am currently a Bcs. Physics senior year student, and you inspired me since my childhood, thank you for that. I hope to make it soon on my term project too..
Good throwback to my old times as a molecular dynamics scientist :) Heating up of your simulation: This is normal and happens for different reasons, the biggest contribution is certainly that your forces are cut off and discretized. There is a difference for incoming and outgoing particles (whenever particles bounce, they heat up a little bit, because not everything is perfectly symmetrical over time). The only way to solve this with 100% correct physics is to go via action integral solutions, which is absolutely not feasible for a simulation of that size, that is why even physicists don't use that for molecular dynamics (MD). The easy and cheap way here to go is to introduce a thermostat, which for example every 100 or 10k frames readjusts the temperature, by shifting the speed of each particle a bit more in the direction of the desired speed. In your case you don't need to care about real temperature, just pick an average speed that you are aiming for, which means you still set the temperature but don't know the value in terms of K or °C. Incompressibility: Be happy you don't have it. You don't want it. It is not a good thing for discrete particle simulations. This is something for totally different methods like finite volume/element simulations, density functional and such things. If you have discrete particles exchanging forces, don't try incompressibility. It is unphysical and it only works in more abstract and less close to real physics. Even in these fields it ends up with singularities and problems everywhere, ask people who try to model turbulence ;-) Behavior at the boundaries: This is no surprise. You have this behavior because the particles at the edges do not have any force pulling on them from the other side. They only have forces pulling on them from the inside and along the boundary but not from outside. This increases their local density there. In MD simulations there are several solutions for this. Often simulations have periodic boundary conditions, then this problem is mostly gone. In your case this is not a solution. You can have a background field that is outside of the box, which is calculated from what is happening inside the box, fast fourier transform is used to calculate that cheaply, this basically means that you copy your box abstractly into each direction, so the particles feel long distance forces from all sides. This is really important for MD simulation to get proper bulk behavior of materials, but in your case this is absolutely not necessary as you do not care if your fluid has a realistic volume viscosity, density, temperature / pressure relation etc. pp. You don't care about physical correctness, so you don't need to go that costly route (especially coding it from scratch). Another solution is to not have "neutral" walls. Your walls can have forces too, which results in the walls being sticky or repulsive, changing the behavior. The easiest solution would be to put ghost particles on the walls, which just emit the same forces as your other particles, but do not receive anything and do not move ever. This is often used in simulation of pores and confined materials. The ghost particles will certainly imprint a structure on the wall (and pull real particles into that structure), which you might not desire. In that case a homogenous wall force might be more what you are looking for, that is basically the same thing, but smooth, so that particles do not stick to certain points on the wall, but just still glide, without higher local density.
As someone who works with SPH I am almost bursting of joy. Thank you so much @SebastianLague Consider using Artificial Viscosity (Monaghan et al.), diffusive density terms (Antuono et al.) and particle shifting technique (Sun et al.) to improve your simulation. Make sure your CFL conditions are correct. You can use kernel corrections to improve accuracy at the fluid boundary (Sheppard or CSPM (expensive)). For surface tension, use the CSF model (Morris is a simple enough model).
Not having any experience in the field i just assumed the boundary conditions arrise since he does not consider the density outside the bounding box or the pressure of the "air" obove, so his pressure gradients push particles outwards
Not quite. Allow me to make it a little more abstract: SPH is a way if interpolating a mathematical function (or continuous field in 3D), but it depends on particle distribution. If you want to approximate the constant number 1, you calculate = sum(1 * vol_j * W_j), with symbolizing SPH approximation, volume and kernel W. Ideally that would sum to 1, but at boundaries you don't have particles everywhere, so you get an error. Conseptually, a "missing particle is like interpolating 0. (0 * vol_j * W_j) That also arrises when particles move and have uneven distributions. For function interpolation (no derivate) that's pretty easy to fix: you just normalize = sum(f(x) * vol_j * W) / sum(vol_j * W) But for the gradient you have directionality (+/-) in 3 dimensions (x,y,z). Thus matrix calculation and getting their inverse is required. And this procedure is called corrected Corrective Smoothed Particle Method (CSPM). It is zeroth order consistent (constant gradients remain constant). There are higher order accurate schemes for gradient correction (e.g. Finite Particle Method (FPM), 1st order consistent), which are more taxing In summary: Because particles aren't evenly distributed everywhere, you need to correct your methods, which approximate the math of the governing physics that drive your simulation, in order the accurately approximate the physics. For gradiends, depending on accuracy use CSPM (0th) or FPM (1st)
Oh wow thats a lot for a non native speaker :D but if i get you right we correct the gradients based on the assumption that we have somewhat mundane situations (air pressure=water pressure at the surface etc) and dont look at situations like venting water into the vacuum of space or something which would lead to valid extreme changes in gradient direction?@@mlisic431
@mlisic431 Ahh that's awesome, thank you for all of the information! I have a question if you wouldn't mind taking a look at it! I implemented a realistic ideal gas SPH with an adiabatic equation of state. So I can simulate thermodynamic things like adiabatic expansion; also it's not too hard to add conduction (Monaghan has a good lecture where he discusses that as well, Introduction to SPH by Monash Astro here on youtube). But I'm wondering how one would go about modeling a classic irreversible thermodynamic process: free expansion. I guess that I'll start by looking at the literature on explosions with SPH, but if you have any recommendations that would be fantastic!
hey. I've worked with thermal expansion only in liquids and made bad experience in terms of stability of wcsph. I'm lacking hands on experience with gas phase. In my case i replicated a benchmark proposed by russell et al. "Numerical simulation of laser Fusion additive manufacturing processes using the SPH method." 2018. That is 2D free surface delta-SPH. I reckon Test1 fits your purposes. My intuition tells me that for big expansions, adaptive smoothing length might be worth looking into, to maintain stability (dont forget to average smoothing length upon particle interaction to maintain symmetry). I didn't implement that at the time. Be mindful of kernel correction at the free surface. Make sure your pressure term registers empty particles as a vacuum (i'd have to investigate, but assymmetric pressure term doesnt work, pressure can't be centered around 0 (like Russell)) I hope that helps as a starting point
I've done some fluid mechincs lately, and was utterly shocked (positively, of course) when I saw how fluid like you got it to behave sheerly through trying to enforce incompressibility. Very impressive!
I keep recommending this video to people on reddit - and then usually end up watching it again myself, because it's just so damn good. Thanks for the videos Mr Lague.
I really love your videos. Exploratory/creative coding content like this is easily digestible and it allows your viewers to follow along and take the same steps that you do. Reading a research paper is pretty daunting-- being explained the concepts in plain language is a lot easier :)
My handsome fellow youtuber, I subscribed in your channel because of some cool Blender rigging tutorials and... here we are, 8 years later and you still amazes me with your videos. You make programing a lot more fun, thank you
I feel like "on the brink of pandemonium" describes many of your projects 😂. This was both technically interesting and beautiful, like so many things you make.
@@alpani6805 Yes, we are all well aware of that. But what LevTheDev is referring to is that Sebastian goes out of his way to code interactive simulations for things like the smoothing curves and whatnot as a means to help explain things. It's a lot of work for little progress on the project itself, but helps the audience a lot.
I'm sitting here at the library. I cranked the volume up on my laptop and then "accidentally" unplugged my headphones. Now everyone knows how smart I am for watching a Sebastian Lague video. Seriously though, very cool. It looks so buttery smooth already.
It's always a good day when you post a new video. As always the effort you put in and the amazing simple explanation of a complex topic is much appreciated so thank you a lot for everything. What a legend
Here's a rogue idea for how the fluid sticks to the bounding box: Make the walls of the bounding box a little bit "elusive" by making it strongly repulse the particles instead of preventing the particles to go past it. This will prevent the particles from sticking to it and instead should bounce off of it. Hopefully.
I think that's only the half story, but in its core it's the right idea. The particles accumulate because there is no force coming from the walls that tell the to go in the other direction. So particles must accumulate until a certain threshold is reached that roughly represent the force that would be introduced by the wall. Almost the same logic applies to the surface. Anyway I think you would need some kind of logic that flags particles in a way to determine if they contribute the the rendering of the surface or not, so you should be able to give them special treatment based on this flag. In the case of the walls simply apply the force they experience in opposite direction regarding the angle of the wall, aka dot product. If I'm not mistaken that should result in evenly spaced out points throughout the walls. The actual surface of the water is a little different there is a factor involved that is more closely related to surface tension.
Absolutely wonderful video! I really like that you kept many of the fumbles and mistakes in the video and showed the thought process exactly the way an experienced programmer might or should, instead of just showing us the complex end result. Really looking forward to seeing how you turn the particles into a rendered result. Great video!
It would be cool to see how different particles dispersed in the fluid. Like, start with 50% red particles and 50% blue and just watch them mix and diffuse.
@@ZombieChicken-X Except that color is just velocity. He wants discrete red and discrete blue particles mixing, with no velocity shading. But just mixing 50-50 red and blue particles won't do us any good unless the particles are smaller than a pixel and there are at least two particles per pixel. Obviously, this massively increases the simulation time, even with the cell-based simulation method, so unless we actually use the GPU to calculate all of this, it's computationally unviable at the moment. However, I'm certain one could emulate this by creating a smoothed color gradient using the smoothing circle and gradually shifting each and every particles' color towards this average at their location., performing this shift on the HSV color system.
@@ZombieChicken-X imagine a cup water but colored with red dye and one with blue dye and mixing them together watching the colors diffuse and disperse. he doesnt want to see the velocities, he wants to see diffusion of basically two different liquids
Wonderful, so inspirational. Thanks for showing the code at each step, and also the trial-and-error bloopers where it didn't work as intended, which keeps the whole thing feeling human.
First I must say this was an awesome video, thanks for making it. Now that I've released my new game on steam I have some more free time to do experiments and your video motivated me greatly. Happy to be a patreon, your content is always amazing.
You are the best thing about youtube! I love the witty, not-taking-yourself-too-seriously narration and your voice is - as always - heavenly. My wife is not interested in math/programming at all but has commented many times saying you should read audiobooks for a living :) cheers and thanks as always!
Just came across your channel and as a fluid dynamics student who's starting his thesis using SPH and I'm super excited to see this and I love your approach! It's an awesome video and I'm definitely gonna stick around for more coding adventures! Thank you and have a lovely day
I find your videos really soothing and engaging. You raise the bar for what's considered high quality educational, yet entertaining content. You explain complicated concepts in simple terms, and turned boring and complicated papers into entertaining work of art, and you're too humble about it. I also love how you explain your thought process, what you tried, what did not work, and how you are equally in love with the journey as you are with the end result. I was watching this with my wife, who has about over a year of programming experience. She commented on how clean, readable and pleasant your code is, even though she did not know the language you're using (she did not know it was C#). When I explained that not only the simulation work is done in C#, but also all the graphs and animations are also done in Unity, she was blown away. I'm a Unity employee btw, and I have shared this video with other colleagues on internal Slack. Good reactions, and a few are already fans and familiar with your work. Thank you for a great video!
Something i think would be cool to see is a simulation with different liquids, different colors, viscosity, weight, ect, and have them collide together to see how they diffuse and mix together 😮
I'd love to see some sort of implementation of adding energy - as in heating the liquid. You could then not only plat with different kinds of liquids but watch how they behave if temp goes up. Something like that
I really love coding adventures. They have long been my favorite series on youtube. I feel like this community views the world with a healthy sense of curiosity and wonder. In many ways I feel at home watching these.
Bloody hell, I never comment on videos, but I have to now. You really are a TH-cam prodigy. Every time I watch one of your videos I'm just amazed how much better it is compared to other "gamdev" (I have nothing but contempt for that word), coding or other educative videos. The incredible care for visualizations and editing, the detailed examples of code or even the strict presence of subtitles make your videos so helpful and enjoyable. Thanks and have a good day, cheers!
@@eddiedoesstuff872 Hehehe , sorry, that was a misfortunate choice of words... I think I just have a subtle allergic reaction to the term as it is so brutally overused all over the internet, where on every corner of TH-cam or other sites people keep selling you the "gamedev lifestyle". I guess my brain just created a shortcut between the term and this unique type of narcissism. I'm fine with all the other terms, videogame creator, game developer or whatnot. Sorry, it was just an unnecessary note...
I work doing Computational Fluid Dynamics and this is just awesome. I just wish you'd talked a bit more about conservation of momentum, cause I feel it's one of the most important things for fluid simulations, given that conservation of mass is already accomplished by using a SPH. Otherwise, great work!!! I pretty much look forward to the next episode on fluid dynamics
I think it's so cool that vorticity came about naturally, but only after he added the speculative velocity update! I'm not entirely sure but I think that line helped satisfy the constant density part of navier Stokes? I'm not exactly sure but that is so fascinating
For the boundaries, you could try getting WolframAlpha to calculate int_{-1}^{x} W(x,y,z) dx, which would give you the density if there was a uniform sea of particles on the other side of the wall
Or maybe just damp the velocities along the normals of the boundary surface? This paper might be helpful: "PIC/FLIP Fluid simulation using a block-optimized grid data structure", 2.5.7 Boundary conditions
Absolutely amazing. One of the fastest three quarters of an hour I’ve experienced. I’m loving the iteration: from idea, to concept, to good enough, a bit of polish, and on to the next idea. I can’t wait till the next one!
Awesome video! I've been reading a lot on fluid simulation, mainly focusing on gases. The reason using the predicted position works is because either way, you're incurring some O(dt^2) error, but using the predicted position has an error which tends to slow down the particles, while the initial position tends to speed them up. Consider a particle sliding in a bowl. If you use the position at the start of a timestep, it'll be higher up the bowl and see a larger speeding-up force when it's sliding downhill, and when it's sliding uphill, it'll be lower down and see a weaker slowing-down force. So you end up consistently speeding up the particle. The opposite happens when you use the predicted position. And that's also why the simulations at 30:00 diverge - the smaller the timestep, the more similar the predicted/initial positions become, and the closer you are to the exact value. The most physically realistic solution is to use a higher-order integrator (e.g. RK4) so your error becomes O(dt^5) and small enough to neglect. Then apply some viscosity to achieve the damping you were previously getting from your O(dt^2) error. (There are also other "symplectic" integrators which are designed around conserving energy, which you can also get higher-order versions of.)
By the way, I've been mainly reading about finite-volume codes. Unlike SPH, which deals with particles of fixed shape which overlap with each other, finite-volume codes generally do not overlap, and deal with volumes which store conserved quantities (mass, energy, momentum). They immediately conserve these quantities (since you only ever deal with them getting transferred from one cell to its neighbour). Incompressibility is unfortunately hard, but you can do it using something like a potential-vorticity treatment (where you use an iterative solver to impose incompressibility).
Yes! I was looking for this comment. The true physics should be conservative in the absence of viscosity, so as the time step size decreases, your simulation will be less and less viscous. Fixing the lookahead value to a constant will greatly limit the accuracy of the simulation. If you want to prevent the explosion caused by the high density initial condition, you can instead use gradient descent on the initial condition to minimize the potential energy!
Interesting. Would using "pos + (predictedpos - pos)/2" remove any error in this case? I imagine not, but maybe it could at least _reduce_ it (as compared to picking either extreme)?
That was absolutely fascinating to watch. The evolved behaviour that comes from such relatively “simple” rules coupled to mass computation is amazing to watch. Excellent explanation of your journey and fantastic visuals made this a riveting watch whilst I waited for my bread to bake. Well done 😊
I am in complete awe at this. This might just be the most informative video ever created on fluid simulation. Thank you immensely for sharing this with us.
I made something very like this for my final project at university, using spheres to represent fluid particles with variable density, the posibility of multiple fluids mixed together and sliders for variable gravity. I loved setting the gravity to nothing and watching my fluids float like they were on the space station
This is incredible how much one can learn from a single video: computer science, simulation, physics, mathematics. I do not think that the visual explanation or the choice of the words were a huge influence to learning (it is still important). Rather your personality. Trying and failing all the time, but it does not hold you back. In fact, it makes you curious, just as children behave without fear, expectation or worry. Children do stuff because they like it. They love it. They have fun. And you also have these characteristics which make everyone immersed in your work. As always, good craft!
When the particles settle down you can see multiple different hexagonal lattices forming, and I think that is really cool, because you see those in real life, if you look at galvanised steel those different shades are each their own lattice arrangement that are reflecting light slightly differently and they come from when the zinc coating was still a liquid, and formed those arrangements on the steel surface.
My MSC project back in 1990 was simulating forces in a 3D surface using the Inmos Transputer chip (actually a set of five of them, one controller and four workers). It used a very trivial averaging formula (vertical velocity of cell in next generation is the average of the height differences to its neighbours). It ended up looking quite pretty. After handing the project in, I've barely done anything with computer graphics, sadly. The point of the project was to demonstrate the power of parallelism and message passing rather than accurately model reality. But your adventure is next level and has got me thinking about downloading a games library for Python and reimplementing my MSc project, then moving onto yours. Thanks for the inspiration.
Having struggled all my life with both math and self confidence, I can honestly say nothing has been more therapeutic, constructive, or productive for me as watching Sabastian's coding videos. With each video of his I watch I shed a little anxiety and think a little clearer. "Let's call this array 'Spatial Lookup' because that sounds nice and fancy"! Brilliant.
I don't know why, but so many points in the video just made me grin. An alternative title to this video could be "The beauty of math". For every addition you make to the simulation it becomes more captivating and hypnitizing. Watching the initial steps with, what i would call, fairly little math, you can see how its starting to behave water like. Beautiful video, amazing watch.
I love your videos, mate. It's at the perfect level where I can still follow and covers so many things I want to try doing with Godot. Also please never stop documenting all the ways your implementations fail, that stuff is *so* relatable - I swear I had point for point the same problems as you when I was doing erosion simulation and actually cackled like a maniac when you too got the spikes forming. 😂
I think this is my favorite video of him so far. Good length, dives into some interesting details, and seems not too complicated to write yourself (disregarding the compute shader part). Also leads to very pleasing visual results. Great work all around.
You can also clearly see convection currents being generated at 46:12 as the boundary volume shrinks, showing that while it probably isn't as realistic as one would like, it is still fairly realistic.
Honestly really interesting video. Much more than I expected from the subject. I particularly liked it when you started going into spatial indexing with a grid (forget the name of the exact method you picked, but basically same idea as a quadtree except uniform grid-sizes etc) and got into stuff like how to turn it infinite without dynamic quadtrees/lists of cells, etc. Though I also liked watching pretty animations before that, as always (you are truly surprisingly good at them, particularly how you turn "writing code" animations into something that manages to retain attention is surprising. (Honestly, overall I can only compare your animations to 3blue1brown). beware for an incoming WALL OF TEXT of my ponderances, observations, and impressions, noted down throughout as I watched the video :) 24:00 I was like "of course!" when you mentioned multiplying axes by primes :D Though you should imo have expanded a bit on the hashing, as ie. "3" and "2" are primes (coprime, even), but (2,0) would end up with same hash as (0,3), so explaining what properties/kinds of primes are desired would have been nice. Additionally, there was no mention of the risk of collisions, and *_why_* it is mostly a non-issue (at most you additionally calculate that extra grid-cell unnecessarily literally no change in result - optimization was 'robust'), with any hit on performance being utterly unnoticeable). While I figure it is something rather intuitive if you understand this part, I still think it deserves highlighting for ppl who stumbled because they assumed hashes must be unique, or simply didn't consciously think of this and might appreciate having this fun 'robustness' in the optimization pointed out. Spatial indexing is honestly such a fascinating subject! 25:00 When you mentioned the sorting, I started further pondering on how the nature of modifications over time play at the sorting algorithms that should be used. Like, I imagine that as the simulation plays only a few particles might change cell at any point, so even if a sorting algorithms worst-case is bad, it might be worth using over others if it handles cases where only a fraction of the list is out of order well. Maybe even ones that require being told _which_ indices has moved out of order. Would have been nice to have mentions on your thoughts and work on this topic. Or maybe if you decided to not run sort once per frame (that needed it), and instead make Removal and Insertion (aka Modify) operations ensure the list remains sorted? If so, how worthwhile is that to simply running a sort instead, how many particles would need to be out-of-order in a single frame to warrant sorting-per-frame over using a sorted data-structure? 25:50 Not a fan of how you represent start indices here. The infinity values makes sense when you understand what you are doing, but not only does it not truly exist in code (apart from the few languages where it does), but it also implies existence of such a key in the lookup table. I would much have preferred something like an Option/Result type ("[None, None, Some(0), Some(3), None, ...]"), or if you imagine it risks needing another subject explained, simply use obviously invalid values like "null" or "-1" (I have difficulty ppl watching this video not understanding null values, but negative values is guaranteed to be understood once mentioned how there are no negative indices in a list). 26:00 oh, you did end up explaining collisions. Would much have preferred to see this mentioned back at the hashing section, rather than the very end of spatial indexing. 26:50 so we now see you decided on sorting per frame (I imagine this is best for this many particles). But any thoughts on which algorithm? I know you are using Array's default, but would love to hear any considerations you might have had :) 27:10 I appreciate being shown the hash stuff :) Was curious which primes you would pick, and see you decided on somewhat large ones, as is generally desired for has functions. 28:20 I think it _is_ actually a "somewhat usable solution"? Fairly sure I have heard of "easing in the physics" as being a not too unusual thing to do with simulations, and particularly I have a (very) vague memory of a 2minutepapers video about a liquid simulations where they _did_ "ease in the physics"? 28:40 Why is this so much better? I have some thoughts, but can't feel certain about them and would have loved further indepth explanation on this. Also, would doing something like "position + (predictposition-position)/2" (getting the position between current and predicted) be a further improvement? Or worse? And does the "step frame-by-frame" work in reverse? Or is this an irreversible process? 30:30 that's interesting behaviour. Any idea why this is, what might have been the issue, and how/what you would need to do to solve it? Also, damn those are some satisfying animations/simulations to watch, The velocity heat-colors really adds to it :) And vortices looks so good with that! 32:40 I'm noting that the particles seem to like hugging the wall a lot. Unsure why, but I do find it funny as it appears to be an unintentional implementation of surface tension making water like to climb up the sides of a glass slightly. Could you try having a straw of those walls lowered into the fluid to see if there will be capillary action too? Oh, you kinda mention this later, though not mentioning how this causes that "stick to glass and travel a bit up the side" behaviour. 38:20 Those negative nearpressures actually made for cool effects. I wonder what other fund stuff you could reappropriate this project for if you use that. Maybe something space like? Or like your mold simulations, maybe simply for making cool-looking animations? I also can't help but imagine games taking place in it... btw, the nearpressure kernel, how can it not mess up the simulation despite having nearly the same radius as the other one, and almost never be less than 50% of it? Or is the smoothingradius secretly much lower for the nearpressure, or the spike spikier than the graph suggests? 40:00 always love your compute shader bloopers :D Look funny, and in a world where we almost only ever see the final results, this kind of thing does really help lower impostor syndrome feelings. We all go through those iterative processes. PS: that one at 40:44 was _really_ cool. Reminded me of something kinda like electricity. Would love to see something more, based on that. 41:00 ooh, another really fascinating subject! Would have loved more indepth on this topic. Also, I imagine you used unit-testing to sanity-check this code? As I imagine trying to figure out it's wrong from looking at a fluid simulation would be difficult :p :D 43:40 ooh, (2 frames of) cool interference patterns at the lower left!!! ...wait ..interference in the velocities? Interesting! 44:40 makes me wish to see the capillary test again, as well as makes me really interested in seeing a siphoning test (does momentum in the fluid make a siphon continue to operate after being started? In conclusion: really impressed by all you did, learned some stuff, had new questions created, and immensely enjoyed all the mesmerizing animations! :)
Sorting: since adjacent cells are not adjacent in the hash list, moving one object to another cell potentially moving most array entries over by one position. Since the complexity of sorting is just a bit worse (n log n vs n), and there might be many cell transitions per frame, the sorting approach is probably asymptotically optimal. Why is this so much better?: A big part is that this integration scheme underestimates the kinetic energy of the particles, and that makes them slow down faster. It also has a lower integration error, which is probably good to have in general. Your idea is close to a method that's actually used to improve integration: evaluating the acceleration at start- and endpoint, and taking the average (f(position)+f(position+speed)/2). It's called Heuns method. As it stands, it is not perfectly reversible, since the original "predictedPositions" estimate is lost. The actual next-step position differs by the acceleration, and since that depends on the predictedPositions, it's exact value is not recoverable. You could however approximate it reasonably well (simply integrate backwards). that's interesting behaviour: the "intended" bahavior is actually the misestimation of the kinetic energy (making the particles slower than they "should" be, given the high initial compression (it's like a pressure canister explosion)). More steps means lower error -> the slowing down of the particles is replaced by a more "physically correct" simulation. stick to glass: it's actually a consequence of the density difference between the inside and outside of the box - the particles are "attracted" to (or rather, pushed against it by the liquid) the relative vacuum on the outside (nothing "reflects" the density force from the wall), and slowed down by repeated contact with the wall. Ie. "freezing vacuum walls"... Walls (or pairs of walls) within the liquid would slow it down (drain energy/speed with each collision), but show no "capillary action", since the water acts across the walls (the missing expected action from "water" on the other side of the wall is what causes the strange behavior). nearpressures: the nearpressure is very similar to the normal pressure, so if anything, it would just reduce the effective density by a bit (the behavior of a gas is pretty robust concerning different repulsion geometries). Also, the "preferred" distance between the particles was probably already beyond the region where the nearpressure has a significant impact. You'd expect to see waves in a fluid, and waves do tend to form interference patterns :) siphon: this simulation has neither air pressure nor significant enough intramolecular attraction (the tendril formation means the liquid has negative surface energy, at least in 2D - ie. you could never siphon bulk water, at most single "strands" of water, and probably only in very weak gravity), nor capillary effects (a side effect of surface energy). So no luck in the current version.
@@sh4dow666 stick to glass: right, thats obvious now that I think about it. beyond the region where the nearpressure has a significant impact: except they had the same smoothing radius, and almost never less than 50% the amplitude (I think it did at the very fringes of the radius, but even slightly in and the difference is small). Yes, interference patterns was expected. Except I expected them to appear in the form of density. What was interesting here (aside from simply the "whoa pretty pictures~", which admittedly is something I enjoy with this creators videos) was how they were in the form of velocities instead (I do imagine it comes from the velocity equalization). siphon: you don't _need_ air-pressure to power a siphon. It is enough that there is a momentum in the liquid (which could manifest from unexpected parts of the implementation - particularly the velocity equalization might provide enough of an adhesive force for a started siphon to continue running. If only for a short while as they probably don't spawn infinite amounts of energy into the system. They also like sticking to eachother as we saw in 43:45, and although this might be caused from the aforementioned, it still does show potentially for forming a band pulling out liquid from the raised reservoir).
Idea for rendering: You could try to implement the marching cubes algorithm to generate a mesh for it. Since you can already calculate the density at any point in space, this might be pretty straightforward. Marching Cubes is essentially used to approximate a boundary of some sort of single value field, like a density field!
Hmm, the same stuff he did for clouds (taking a noise-field and march cubes over it to generate a mesh) could surely be used for the water-rendering, yeah?
crazy how i can watch you do every single step, hear you explain everything so simply and yet the end result feels like magic like the world is really just made up of math isnt it
Love the 3Blue1Brown plushie cameo. Been looking forward to this video since you first teased it. Though a couple things to note. Firstly, if it wasn't clear, Sebastian is using Freya's "Shapes" asset to draw the circles, which isn't native to Unity. It's a paid asset. (He mentioned that in his video on how he makes these tutorials.) Secondly, it's not really clear to me how the blurring is done, but I suspect that's also a feature of Shapes as well. Would be nice to have Seb confirm or clarify those points.
Yes!! Was waiting for this one after I had watched Acerola video about ocean simulation and wondered how this fluid simulation project of yours is doing (since you mentioned it back in the AI game challenge). Question answered
A really underrated quality of this sort of basic simulation is it shows how fundamental properties are-stuff like the fluid levels on both sides of a barrier staying even, etc. All a “fluid” needs to have these properties is just the basic density pressure functions, and this is a real physical effect.
I just need to say that I find it very encouraging that you are paying the cat tax up front. I hate it when people have cats, and don't pay the cat tax on their videos.
This reminds me of a game I had on my phone years ago, where it was basically the same 2 dimensional fluid but you could only pick up the fluid. Great video
Hey, physicist with experience in numerics here. First of all, great stuff! A few comments: Pretty sure the "prediction" part of the code is only helpful since it effectively makes the particles repel from their own future versions, which in essence means they experience a global damping force - this both explains why it "calms" the dynamics, by being the only mechanism for the system energy to lower (apart from the more realistic damping you added later), and possibly why it depends on the prediction timestep. I'd recommend just getting rid of this and using only the more realistic damping, unless that doesn't work. Also, did you try using some other spatial partitions, such as KDTrees? They might be better, though honestly I doubt it. Another neat option would be to instead of calculating the actual average quantities per particle, calculate a rough scale approximation for the average quantities per cell, and use that for approximating the effects of any far away particles (say, those further that R/3 or so) - this is similar to the Fast multipole method, though for such local interactions which decay quickly it again might just be wasteful. Oh, and, maybe try some symplectic integration schemes, such as Verlet or even something better (note that even though you have damping forces, which make your system non-Hamiltonian, you could just plug the force directly instead of dV/dq and get nice results) - I didn't mess around with these much, but I've seen claims they greatly improve long term stability for integration (i.e. better conserve energy for the same amount of compute). Oh, and for the boundary, at least against walls you could treat each wall like a really long and flat particle, manually adding a set density from them to the local density estimate. I don't know how to treat the free boundary "collapsing" though, maybe messing around with the near-repulsion term a little?
on the KDTrees part, i believe he made a small footnote that he might experiment with them which means he likely didnt attempt it, i dunno though, might just be hallucinating
The "prediction" part of the code is actually analogous to the backward Euler method, ie. a more stable numerical integration scheme with less truncation error per step. It would probably be even more stable to use the Heun method (use the average between the current and the extrapolated position), though that would increase the frame time... ((in the specific example in the video, the backward Euler method has the advantage of underestimating the total kinetic energy, while the normal Euler method overestimates it. So if starting off with particles under really high pressure, any kind of energy underestimation probably helps... Simply making the initial packing less dense would be the most elegant solution tho)) Dampening might mask the integration error, but for a realistic simulation it still shouldn't be ignored. I don't have any practical experience with symplectic integrators, but I'd assume them to be relatively costly computationally, and since we have a dissipative system, they might not actually be much better then Heun/RK4 integration in practice. The density interpretation doesn't really help my intuition, but I'd guess the reason for the isolated surface layer/tendrils is energetic - ie. surfaces are energetically favorable compared to bulk states at low pressure (or at least a local optimum reinforced by the gravity induced flatness of the surface). I'm really curious whether sufficiently low gravity would cause a 2nd isolated layer to form, or perhaps even dissolve the existing one? I'd also guess it would be the attractive term, not the near-repulsive one, which is the primary cause of tendril formation in this simulation. btw, 13:44 shows really nice surface formation in the middle while in zero-G. So getting the gas to form droplets instead of surfaces (minimize surface area, instead of maximizing it) by tweaking the terms definitely seems to be the way to go to prevent tendril formation.
Games aren't like engineering fluid dynamics so I disagree about the prediction part. The state of the art for real time fluids is actually to get rid of SPH, leaving only the density computation, and instead solve the particles via constraints via newton's method. Of course with newton's method you'll make an even more crude prediction and then adjust multiple times per time step, which leads to even worse global damping (solved via introducing aritifical constraints) Yes, this is nothing like what a physcists would do, but this is computer graphics, not physics. The position based constraints give nearly identical visuals but performs much better for a wider range of time steps, and is less susceptible to tensile instability.
@@sh4dow666 I'm making my own video, but it will have all the steps: simulating, rendering, external object interaction, and control (turning water into the shape of meshes and animating them). The integrator isn't the issue here imo. The real issue is the way the simulation is being solved via SPH, when it's more efficient and stable to solve via density constraints alone. Which is pretty obvious during the video once he runs into incompressibility issues (common flaw of standard SPH).
For my masters thesis I have actually used your Marching Cubes algorithm from the Terraforming video to render a fluid amongst other methods of rendering. Raymarching was one rendering technique I gave up on due to the limited time I have for the thesis. Allthough I would love you see your spin on it at a later point.
I looked at the Screen Space Meshing Paper from Matthias Müller which creates a new Mesh every frame that fits the viewport frustums view of the Particles and am currently stitching together some old Nvidia Papers for direct rendering as basically a post process shader by rendering the Particles into a depth buffer, smoothing that, creating normals from that depth map and then shading that. Was a GDC 2010 talk named "Screen Space Fluid Rendering for Games" by Simon Green. It compliments well with another paper from Simon Green called "Screen space fluid rendering with curvature flow".
Hi everyone, I hope you enjoy the video! This is a topic I’ve been wanting to tackle for ages, but have always found a bit intimidating to get started with.
So I’m happy to have finally dived in! Let me know if you have any suggestions for improving it, or ideas for future projects.
In other news, I’ve recently created a Ko-Fi page where it’s possible to support my work with a one-off contribution (as opposed to the monthly pledges on Patreon).
No pressure of course, but if that’s something you’d like and are able to do, you can find the page here ko-fi.com/sebastianlague
@@sfsasteroid1 Yes, I definitely want to get back to that project. Hopefully soon!
I liked the video overall, but the first half was a slog to watch through. I like how acerolla approaches writing a script for that, maybe you could do something similar if there's lots of math involved.
Could you also create more videos about shaders and how beautiful and realistic they make the “world”?
I wrote a reply before but I think it was removed because I included links. Anyway, I highly suggest you look into a fluid simulation method called FLIP (Fluid Implicit Particle), it's also primarily a Lagrangian or particle based method, like SPH, but it achieves improved conservation of quantities like density, and better divergence, by incorporating aspects of finite volume simulations, so it should address many of the issues you've noticed so far with pure SPH being more gas like. Considering you already have the particle code working, building an implementation of FLIP should be fairly easy as most of the changes it requires are calculating some quantities like velocity on a fixed grid rather than at particle locations. FLIP also happens to be one of the default fluid simulation methods used by commercial software such as Houdini, and is available as a very popular Blender addon too, so there's boatloads of work that's gone into optimising, much of which is available for free online. The paper I linked before was titled Flip: A low-dissipation, particle-in-cell method for fluid flow, if you want to learn more.
I'd love for you to make a truly incompressable simulation, since this might also allow you to simulate stuff like sand or wheat
The near-density trick was something I came up with for my master's thesis 18 years ago, and nobody mentioned that they were using it before today. It took a long time, but it was worth it in the end because I got my name in one of best videos on youtube. Thank you Sebastian.
Thank you for the super-helpful paper, and I’m so happy you liked the video!
I'd say that deserves at least a like
Maybe the same behaviour can be obtained by including a local minimum to the "interaction" function, so that particles tend to keep a certain distance to their neighbours, not more not less. The constant density would be an emergent property.
A local minimum in the interaction function would also provide a "boiling point": if the energy of the particles is higher than the well depth, the particules break their "bond" and fly with more freedom.
Much respect
The real insane part of these videos isn’t the coding is the visualisation of the coding at the same time to make it so that non coders can understand clearly, I love these videos
Even people who do code benefit from the beautiful visualizations! It's just an all around great thing to include
Kind of like how accessibility features benefit everyone
I like this channel a lot 😊
It's insane how much time he invests for visually explaining clips that end up being 10 seconds, while they can easily sometimes take hours to create
@@MayaPapaya497 Honestly, yeah I wish programming tools had those sorts of visualizations right out of the box. It would make debugging so much easer and less mentally abstract if you could see what was happening.
Honestly making everything as interactive and visualizable as he does is probably as much or more work then just getting the actual equations to work. Though I guess Unity helps a lot with that.
unity ❤
I personally would love to see a "deep dive walkthrough" on you porting this to the GPU. It seems like a great vehicle for introducing a lot of people to GPU programming. You mostly did that part "off screen" here - those details would be hugely interesting, I think.
I think he made a video on compute shaders where he goes over a lot of the techniques.
ditto this request! And please do it in taichi!
I found that analysing and modifying his marching cubes terrain source code was really informative.
This is a good video: "th-cam.com/video/BrZ4pWwkpto/w-d-xo.html
"
The worst part about Sebastian Lague videos is that they end.
Absolutely HATE when that happens :(
Ong😭
The best part is that my memory isn't infallible, which means I can rewatch old videos
Wisdom to put on a bathroom tile and hang in your kitchen.
He is my favorite tumblr scrimblo
Sebastian Lague never disappoints. I am astonished by how much a single man can accomplish, and at the same time, how much he can teach others. The 48 minutes that this video lasted felt more like 10 because of how enjoyable and informative it was. I can't wait to see how the finished product will look like. Amazing work!
My problem is that these videos are often a bit too complicated to wrap my mind around, and therefore I have to watch them twice to understand. But that's probably also because I'm not a native speaker.
Despite that, this channel is one of the best in explaining.
@@murmeldinAlthough I really like his videos, I do not believe that he codes these projects alone.
@@hypertizerWhy? Most of the time his projects are based on well documented techniques. He consistently mentions using papers and reference material - that’s really all you need to implement this stuff.
Its very much possible to do all this coding alone. Just takes patience, skill and persistence.
Remember the research was already done in the papers. Not saying it's easy but any decent software engineer should be able to figure out a implementation.
@@hypertizer if someones gonna take like months to upload videos I'm sure he's doing it by his own
It's so fun to watch these as a physicist! On the one hand, if feels like you get just enough of the physics to follow along with your project, and I, on the other hand, get just enough of the programming to follow along with your video.
It's also so cool to see you implementing these ideas. One of my favorite youtube series for sure.
Hello Fellow Physicist!
Can you tell me what kind of engine does real life use to simulate Millions and billions of particles (Atoms) and make them interact with each other seamlessly? I mean.. is there even an engine? or is there something else at play here?
I've been wondering that for the longest time 😭
@@ashlysherief3850 oh yeah real life uses a very complicated engine it is called physics and it has no documentation
@@ashlysherief3850 Gromacs, NAMD, Amber, OpenMM are the most used ones if we're talking about fairly accurate, atomistic, classical simulations. And yes, with multi-gpu or even better, multinode clusters they can simulate even tens or hundreds of million of atoms. They get nowhere near "real time" speed though. Usually it takes months to accurately model big biomolecular systems for just a few tens of microseconds, or a few milliseconds. The problem is that atoms are really really fast, so your simulation step must be about a few femtoseconds. The faster you allow your particles to go, the slower will be the simulation, and with realistic atomist systems you really don't have a choice. BTW they mostly use the leapfrog (Verlet) method for the integration of the equations of motions, which Sebastian mentions, but then they also add stochastic terms in order to sample from the correct distribution of temperatures and pressures.
@@sayorancode yeah the coder who came up with it doesnt seem to be answering any emails and apparently left the project as it is a long time ago
Sebastian comes back every once in a while like a Santa to bless us with heavenly vibe
fr
you have great taste in the videos you comment on
This is number 91
@@penewoldahh You think they have great taste because they comment on literally every popular video, so the ones you watch you will see their comment.
@@Nae_Ayythe video had 9k views at the time of my comment. It had less when heisenbergfam commented. This was not popular
Developing these prototypes requires a lot of work. The fact you go the extra mile to create visual graphs on what is currently taking place using the Editor itself and no editing tricks is ridiculous, you take a great deal of pride in your work! You are a very smart man!
I think at his level, trying to learn editing tricks would be slower.
The way you timed up the music with the waves at 45:58 was so clean 🤌 love the production quality you put into these videos
I think he uses DaVinci Resolve
Super cool video! We need part 2 👁👄👁
yoo! danis here (im a big fan
you need a part 1 to literally anything first bro 😭
Duuude, where you been?
He isn't dead! :)
Yo, its the milk man! His milk is delicious
This is extremely cool! There's something about the combination of particle-based systems and fluid simulations that is fascinating. I ran into a lot of the same problems while trying to implement a particle-based fluid visualization where the underlying simulation is not actually particle based. A lot of the techniques you showed would definitely be applicable to this problem and I'll look into them a bit more. My solution was just giving up on trying to match the density with the particles and instead make the particles act more like dust that is pulled and pushed by the fluid's motion. It works alright but suffers from its own set of issues... Anyway, great video as always!
Thank you! I don't know if I've said before, but your simulations are super impressive and always really fascinating to watch. I'm excited to catch up on the latest videos (now that I've finally finished editing this)!
Omg its the engine simulator guy. Huge fan
woah it's the trumpet simulator person
Please do a collaboration, you two!
@AaronStatic I do think if two or three of these GOAT coders worked together they would fix humanities problems. Genius
I did a compsci degree at a decent university many years back... this video is astounding quality and right up there in terms of lecturer quality... and it's free!
Sebastian didn’t end his video with “cheers”.
My conclusion is that he’s been kidnapped and had to send a secret message that only we’d understand something was weird about.
The chessbots must have finally got him.
Read this before I've finished the video, son's crying now... Cheers.
I feel like he's smiling through his teeth the entire video.
I'm pretty sure his cat made this one. The cat was covering the keyboard in almost every shot.
This is truly inspiring and the production quality is amazing as well, thank you!
I also picked up a few notes for spatial search optimisations I'm excited to try out in my little evolution sandbox simulator
Thanks! And that's awesome, I'm happy to hear it!
Excited to see fluid sims in my poe filters 👌
Truly amazing how this comment is reading as created 21 hours ago when the video was uploaded an hour ago
@@kalledk21 Haha, that's one way to liquify your currency in Path of Exile I suppose :)
@@xu_fengxuanim pretty sure members get early access
Hi, Huge respect for your work. I am doing right now my thesis in fluid dynamics. I have written already about all math basics. In your video I have not only visualisation but also you share with everyone how to creat code for it. During my studies I was writing the code for movement of the buoy on the waves. I spend lots of time to do it with supervision of my porfesor. I felt like a child id the fog. After your video I have comprehend all knowlege from my Naval Architect studies. Huge respect and thank you thousand times.
Have been waiting for a fluid simulation video for 10 years, thank you Sebastian.
I'm not sure it can live up to 10 years of anticipation, but I hope you enjoy it nonetheless :) Definitely a topic I'll be exploring more in the future too.
@@SebastianLague any ideas for future experiments involving AI-related algorithms? I would love watching a revisit to Ecosystem Simulation (probably one of my favourites) with Q-Learning, perhaps
Gonkee has a similar video, but he doesn't explain how it works
Great video dude@@SebastianLague
This is probably the only channel where I can watch an almost hour long video and not get bored for a tiny second
fr bro
While not understanding half of the stuff happening lol
i didnt even realize it was almost an hour long
the visualization here is better than marvel sgi
You do realize that all of NY city was cgi. so I wouldn't go that far, but his visualizations are very impressive none the less.@@Basuliic
I barely understand anything about how coding works, but your videos are not only relaxing, but somehow make it so easy to understand whats actually happening. Always are great day when a new Coding Adventure releases! Also, cute cat.
I love how one of the bugs you try to fix is just emergent surface tension.
That's what even I thought
Yes, I thought the same. That's likely exactly what it's supposed to do. There's no pressure from the other side, and that affects the distribution of particles.
It is sort of like surface tension but not really. Because of the function he picked, his water is compressible. And it shouldn't be.
@@RothronThat can be mostly fixed by turning up the pressure multiplier.
@@Rothron Only weakly compressible, right?
I love how the water particles simulate adhesion and cohesion naturally… so cool… (33:05)
An absolutely classic Lague video
It's been 8 minutes (I agree)
Edit: nvm patron
hi oziji
hi zorby
That's how you spell it? Always thought it was league lol
League*
He is the Bob Ross of Coding. He is like: „Lets put a happy little rekursive non-linear differencial equation of sixt order here.“ I love it!
absolutely spot on!
"This bug is a happy accident if you look at it this way"
And let's but another one next to it, because everyone needs a friend
I am currently a Bcs. Physics senior year student, and you inspired me since my childhood, thank you for that. I hope to make it soon on my term project too..
Good throwback to my old times as a molecular dynamics scientist :)
Heating up of your simulation:
This is normal and happens for different reasons, the biggest contribution is certainly that your forces are cut off and discretized. There is a difference for incoming and outgoing particles (whenever particles bounce, they heat up a little bit, because not everything is perfectly symmetrical over time). The only way to solve this with 100% correct physics is to go via action integral solutions, which is absolutely not feasible for a simulation of that size, that is why even physicists don't use that for molecular dynamics (MD). The easy and cheap way here to go is to introduce a thermostat, which for example every 100 or 10k frames readjusts the temperature, by shifting the speed of each particle a bit more in the direction of the desired speed. In your case you don't need to care about real temperature, just pick an average speed that you are aiming for, which means you still set the temperature but don't know the value in terms of K or °C.
Incompressibility:
Be happy you don't have it. You don't want it. It is not a good thing for discrete particle simulations. This is something for totally different methods like finite volume/element simulations, density functional and such things. If you have discrete particles exchanging forces, don't try incompressibility. It is unphysical and it only works in more abstract and less close to real physics. Even in these fields it ends up with singularities and problems everywhere, ask people who try to model turbulence ;-)
Behavior at the boundaries:
This is no surprise. You have this behavior because the particles at the edges do not have any force pulling on them from the other side. They only have forces pulling on them from the inside and along the boundary but not from outside. This increases their local density there. In MD simulations there are several solutions for this. Often simulations have periodic boundary conditions, then this problem is mostly gone. In your case this is not a solution. You can have a background field that is outside of the box, which is calculated from what is happening inside the box, fast fourier transform is used to calculate that cheaply, this basically means that you copy your box abstractly into each direction, so the particles feel long distance forces from all sides. This is really important for MD simulation to get proper bulk behavior of materials, but in your case this is absolutely not necessary as you do not care if your fluid has a realistic volume viscosity, density, temperature / pressure relation etc. pp. You don't care about physical correctness, so you don't need to go that costly route (especially coding it from scratch). Another solution is to not have "neutral" walls. Your walls can have forces too, which results in the walls being sticky or repulsive, changing the behavior. The easiest solution would be to put ghost particles on the walls, which just emit the same forces as your other particles, but do not receive anything and do not move ever. This is often used in simulation of pores and confined materials. The ghost particles will certainly imprint a structure on the wall (and pull real particles into that structure), which you might not desire. In that case a homogenous wall force might be more what you are looking for, that is basically the same thing, but smooth, so that particles do not stick to certain points on the wall, but just still glide, without higher local density.
this guy can make the most complicated concepts digestible and he has a calming voice and amazing editing
As someone who works with SPH I am almost bursting of joy.
Thank you so much @SebastianLague
Consider using Artificial Viscosity (Monaghan et al.), diffusive density terms (Antuono et al.) and particle shifting technique (Sun et al.) to improve your simulation. Make sure your CFL conditions are correct. You can use kernel corrections to improve accuracy at the fluid boundary (Sheppard or CSPM (expensive)). For surface tension, use the CSF model (Morris is a simple enough model).
Not having any experience in the field i just assumed the boundary conditions arrise since he does not consider the density outside the bounding box or the pressure of the "air" obove, so his pressure gradients push particles outwards
Not quite. Allow me to make it a little more abstract:
SPH is a way if interpolating a mathematical function (or continuous field in 3D), but it depends on particle distribution. If you want to approximate the constant number 1, you calculate = sum(1 * vol_j * W_j), with symbolizing SPH approximation, volume and kernel W. Ideally that would sum to 1, but at boundaries you don't have particles everywhere, so you get an error.
Conseptually, a "missing particle is like interpolating 0. (0 * vol_j * W_j)
That also arrises when particles move and have uneven distributions.
For function interpolation (no derivate) that's pretty easy to fix: you just normalize = sum(f(x) * vol_j * W) / sum(vol_j * W)
But for the gradient you have directionality (+/-) in 3 dimensions (x,y,z). Thus matrix calculation and getting their inverse is required. And this procedure is called corrected Corrective Smoothed Particle Method (CSPM). It is zeroth order consistent (constant gradients remain constant).
There are higher order accurate schemes for gradient correction (e.g. Finite Particle Method (FPM), 1st order consistent), which are more taxing
In summary: Because particles aren't evenly distributed everywhere, you need to correct your methods, which approximate the math of the governing physics that drive your simulation, in order the accurately approximate the physics. For gradiends, depending on accuracy use CSPM (0th) or FPM (1st)
Oh wow thats a lot for a non native speaker :D but if i get you right we correct the gradients based on the assumption that we have somewhat mundane situations (air pressure=water pressure at the surface etc) and dont look at situations like venting water into the vacuum of space or something which would lead to valid extreme changes in gradient direction?@@mlisic431
@mlisic431 Ahh that's awesome, thank you for all of the information! I have a question if you wouldn't mind taking a look at it! I implemented a realistic ideal gas SPH with an adiabatic equation of state. So I can simulate thermodynamic things like adiabatic expansion; also it's not too hard to add conduction (Monaghan has a good lecture where he discusses that as well, Introduction to SPH by Monash Astro here on youtube). But I'm wondering how one would go about modeling a classic irreversible thermodynamic process: free expansion.
I guess that I'll start by looking at the literature on explosions with SPH, but if you have any recommendations that would be fantastic!
hey. I've worked with thermal expansion only in liquids and made bad experience in terms of stability of wcsph. I'm lacking hands on experience with gas phase. In my case i replicated a benchmark proposed by russell et al. "Numerical simulation of laser Fusion additive manufacturing processes using the SPH method." 2018. That is 2D free surface delta-SPH. I reckon Test1 fits your purposes.
My intuition tells me that for big expansions, adaptive smoothing length might be worth looking into, to maintain stability (dont forget to average smoothing length upon particle interaction to maintain symmetry). I didn't implement that at the time.
Be mindful of kernel correction at the free surface. Make sure your pressure term registers empty particles as a vacuum (i'd have to investigate, but assymmetric pressure term doesnt work, pressure can't be centered around 0 (like Russell))
I hope that helps as a starting point
I've done some fluid mechincs lately, and was utterly shocked (positively, of course) when I saw how fluid like you got it to behave sheerly through trying to enforce incompressibility. Very impressive!
The production value, education, and accessibility of Sebastian Lague’s videos is astounding. Keep up the great work! ❤
I keep recommending this video to people on reddit - and then usually end up watching it again myself, because it's just so damn good. Thanks for the videos Mr Lague.
Sebastian Lague: new video \0/
All programmers while watching: “This part of my life, this little part, is called happiness”
Thank you.
Well said.
That's beautiful :')
This relates harrrd
That perfectly describes my perception of those videos
That made me smile, as did the video. Thank you! 🙂
You're like the Bob Ross of coding! Always a great day when you upload 😁
No bugs, only happy accidents lol
I really love your videos. Exploratory/creative coding content like this is easily digestible and it allows your viewers to follow along and take the same steps that you do. Reading a research paper is pretty daunting-- being explained the concepts in plain language is a lot easier :)
I love how humble and determined he is.
0:38 Sebastian: "Let's keep track of the particle's position and velocity." Heisenberg: "Am I a Joke to you?"
My handsome fellow youtuber, I subscribed in your channel because of some cool Blender rigging tutorials and... here we are, 8 years later and you still amazes me with your videos. You make programing a lot more fun, thank you
I feel like "on the brink of pandemonium" describes many of your projects 😂. This was both technically interesting and beautiful, like so many things you make.
Not only did he learn these concepts and teach them, he built an interactive tool to use as a presentation aid.
Not to take from his amazing work but I'm pretty sure he is using Unity. It's free if you want to try and experiment a bit yourself :)
@@alpani6805 Yes, we are all well aware of that. But what LevTheDev is referring to is that Sebastian goes out of his way to code interactive simulations for things like the smoothing curves and whatnot as a means to help explain things. It's a lot of work for little progress on the project itself, but helps the audience a lot.
Better use Godot and dont support those Unity poopheads @@alpani6805
I'm sitting here at the library. I cranked the volume up on my laptop and then "accidentally" unplugged my headphones. Now everyone knows how smart I am for watching a Sebastian Lague video.
Seriously though, very cool. It looks so buttery smooth already.
It's always a good day when you post a new video. As always the effort you put in and the amazing simple explanation of a complex topic is much appreciated so thank you a lot for everything.
What a legend
Thank you! :)
That 3blue1brown plush was so fitting with the math refresh, glad to see him also enjoy the obscure math problems and their explanation
Here's a rogue idea for how the fluid sticks to the bounding box:
Make the walls of the bounding box a little bit "elusive" by making it strongly repulse the particles instead of preventing the particles to go past it.
This will prevent the particles from sticking to it and instead should bounce off of it. Hopefully.
That would make sense since the wall is also made of particles in real life!
I think that's only the half story, but in its core it's the right idea. The particles accumulate because there is no force coming from the walls that tell the to go in the other direction. So particles must accumulate until a certain threshold is reached that roughly represent the force that would be introduced by the wall. Almost the same logic applies to the surface.
Anyway I think you would need some kind of logic that flags particles in a way to determine if they contribute the the rendering of the surface or not, so you should be able to give them special treatment based on this flag. In the case of the walls simply apply the force they experience in opposite direction regarding the angle of the wall, aka dot product.
If I'm not mistaken that should result in evenly spaced out points throughout the walls.
The actual surface of the water is a little different there is a factor involved that is more closely related to surface tension.
Just make the visual edge of the wall outset from the "physical" edge of the wall. It's a quick and dirty hack but it would look fine.
Fluid simulation is probably one of the holy grails of indie gamedev. Great work!
Unless your entire game revolves around the fluid simulation, you're not gonna be looking to implement one
47 minute Sebastian Lague video?
Heck yeah!
Love seeing these very charming and interesting programming projects you do. It's a lot of fun!
Absolutely wonderful video! I really like that you kept many of the fumbles and mistakes in the video and showed the thought process exactly the way an experienced programmer might or should, instead of just showing us the complex end result. Really looking forward to seeing how you turn the particles into a rendered result. Great video!
It would be cool to see how different particles dispersed in the fluid. Like, start with 50% red particles and 50% blue and just watch them mix and diffuse.
you can kind of already see that, red just means fast and blue slow. When the waves crash you are effectively seeing that
@@ZombieChicken-X
Except that color is just velocity. He wants discrete red and discrete blue particles mixing, with no velocity shading.
But just mixing 50-50 red and blue particles won't do us any good unless the particles are smaller than a pixel and there are at least two particles per pixel. Obviously, this massively increases the simulation time, even with the cell-based simulation method, so unless we actually use the GPU to calculate all of this, it's computationally unviable at the moment.
However, I'm certain one could emulate this by creating a smoothed color gradient using the smoothing circle and gradually shifting each and every particles' color towards this average at their location., performing this shift on the HSV color system.
@@Operational117 I dont understand, so like mixing two cups of water? Or mixing water and milk
@@ZombieChicken-X imagine a cup water but colored with red dye and one with blue dye and mixing them together watching the colors diffuse and disperse. he doesnt want to see the velocities, he wants to see diffusion of basically two different liquids
gotcha@@goldenbananas1389
Very impressive. I also like the fact that you don't hide your mistakes.
Wonderful, so inspirational. Thanks for showing the code at each step, and also the trial-and-error bloopers where it didn't work as intended, which keeps the whole thing feeling human.
First I must say this was an awesome video, thanks for making it. Now that I've released my new game on steam I have some more free time to do experiments and your video motivated me greatly. Happy to be a patreon, your content is always amazing.
Thank you, and congrats on the release! What is your game called?
@@SebastianLague Monos: The Endless Tower
@@mariandev Looks really nice! That's a cool idea to have the game take place along the outside of the tower :)
You are the best thing about youtube!
I love the witty, not-taking-yourself-too-seriously narration and your voice is - as always - heavenly. My wife is not interested in math/programming at all but has commented many times saying you should read audiobooks for a living :)
cheers and thanks as always!
Just came across your channel and as a fluid dynamics student who's starting his thesis using SPH and I'm super excited to see this and I love your approach! It's an awesome video and I'm definitely gonna stick around for more coding adventures! Thank you and have a lovely day
It's a good day when Sebastian uploads.
I find your videos really soothing and engaging. You raise the bar for what's considered high quality educational, yet entertaining content. You explain complicated concepts in simple terms, and turned boring and complicated papers into entertaining work of art, and you're too humble about it. I also love how you explain your thought process, what you tried, what did not work, and how you are equally in love with the journey as you are with the end result.
I was watching this with my wife, who has about over a year of programming experience. She commented on how clean, readable and pleasant your code is, even though she did not know the language you're using (she did not know it was C#). When I explained that not only the simulation work is done in C#, but also all the graphs and animations are also done in Unity, she was blown away.
I'm a Unity employee btw, and I have shared this video with other colleagues on internal Slack. Good reactions, and a few are already fans and familiar with your work.
Thank you for a great video!
Something i think would be cool to see is a simulation with different liquids, different colors, viscosity, weight, ect, and have them collide together to see how they diffuse and mix together 😮
I'd love to see some sort of implementation of adding energy - as in heating the liquid. You could then not only plat with different kinds of liquids but watch how they behave if temp goes up. Something like that
A cool project could be building a unity museum where you could walk through and see/interact with all of your different coding adventures projects
they could all be on their own planets, from the solar system video
Since it's Lague doing these things and not Unity, he would need an SL logo, coding adventure or something specific.
I really love coding adventures. They have long been my favorite series on youtube. I feel like this community views the world with a healthy sense of curiosity and wonder. In many ways I feel at home watching these.
Bloody hell, I never comment on videos, but I have to now. You really are a TH-cam prodigy. Every time I watch one of your videos I'm just amazed how much better it is compared to other "gamdev" (I have nothing but contempt for that word), coding or other educative videos. The incredible care for visualizations and editing, the detailed examples of code or even the strict presence of subtitles make your videos so helpful and enjoyable. Thanks and have a good day, cheers!
Why do you have so much contempt for the term gamedev?
@@eddiedoesstuff872 Hehehe , sorry, that was a misfortunate choice of words... I think I just have a subtle allergic reaction to the term as it is so brutally overused all over the internet, where on every corner of TH-cam or other sites people keep selling you the "gamedev lifestyle". I guess my brain just created a shortcut between the term and this unique type of narcissism. I'm fine with all the other terms, videogame creator, game developer or whatnot. Sorry, it was just an unnecessary note...
I work doing Computational Fluid Dynamics and this is just awesome. I just wish you'd talked a bit more about conservation of momentum, cause I feel it's one of the most important things for fluid simulations, given that conservation of mass is already accomplished by using a SPH. Otherwise, great work!!! I pretty much look forward to the next episode on fluid dynamics
I think it's so cool that vorticity came about naturally, but only after he added the speculative velocity update! I'm not entirely sure but I think that line helped satisfy the constant density part of navier Stokes? I'm not exactly sure but that is so fascinating
For the boundaries, you could try getting WolframAlpha to calculate int_{-1}^{x} W(x,y,z) dx, which would give you the density if there was a uniform sea of particles on the other side of the wall
yes or extend the particles beyond the boundary and only render those within
@@Ra99y This would make particles suddenly dissapear. An interesting tradeoff though.
Or maybe just damp the velocities along the normals of the boundary surface?
This paper might be helpful: "PIC/FLIP Fluid simulation using a block-optimized grid data structure", 2.5.7 Boundary conditions
Absolutely amazing. One of the fastest three quarters of an hour I’ve experienced. I’m loving the iteration: from idea, to concept, to good enough, a bit of polish, and on to the next idea. I can’t wait till the next one!
Awesome video! I've been reading a lot on fluid simulation, mainly focusing on gases.
The reason using the predicted position works is because either way, you're incurring some O(dt^2) error, but using the predicted position has an error which tends to slow down the particles, while the initial position tends to speed them up.
Consider a particle sliding in a bowl. If you use the position at the start of a timestep, it'll be higher up the bowl and see a larger speeding-up force when it's sliding downhill, and when it's sliding uphill, it'll be lower down and see a weaker slowing-down force. So you end up consistently speeding up the particle. The opposite happens when you use the predicted position. And that's also why the simulations at 30:00 diverge - the smaller the timestep, the more similar the predicted/initial positions become, and the closer you are to the exact value.
The most physically realistic solution is to use a higher-order integrator (e.g. RK4) so your error becomes O(dt^5) and small enough to neglect. Then apply some viscosity to achieve the damping you were previously getting from your O(dt^2) error. (There are also other "symplectic" integrators which are designed around conserving energy, which you can also get higher-order versions of.)
By the way, I've been mainly reading about finite-volume codes. Unlike SPH, which deals with particles of fixed shape which overlap with each other, finite-volume codes generally do not overlap, and deal with volumes which store conserved quantities (mass, energy, momentum). They immediately conserve these quantities (since you only ever deal with them getting transferred from one cell to its neighbour). Incompressibility is unfortunately hard, but you can do it using something like a potential-vorticity treatment (where you use an iterative solver to impose incompressibility).
That makes sense, thanks for the explanation!
Yes! I was looking for this comment. The true physics should be conservative in the absence of viscosity, so as the time step size decreases, your simulation will be less and less viscous. Fixing the lookahead value to a constant will greatly limit the accuracy of the simulation. If you want to prevent the explosion caused by the high density initial condition, you can instead use gradient descent on the initial condition to minimize the potential energy!
Interesting. Would using "pos + (predictedpos - pos)/2" remove any error in this case? I imagine not, but maybe it could at least _reduce_ it (as compared to picking either extreme)?
That was absolutely fascinating to watch. The evolved behaviour that comes from such relatively “simple” rules coupled to mass computation is amazing to watch. Excellent explanation of your journey and fantastic visuals made this a riveting watch whilst I waited for my bread to bake. Well done 😊
I am in complete awe at this. This might just be the most informative video ever created on fluid simulation. Thank you immensely for sharing this with us.
I made something very like this for my final project at university, using spheres to represent fluid particles with variable density, the posibility of multiple fluids mixed together and sliders for variable gravity. I loved setting the gravity to nothing and watching my fluids float like they were on the space station
even though im currently sick, i still wanna watch sebastian lague, don't wanna miss his greatness, do i?
Same here....
Feeling rubbish too! We’ll get through it!
Get well soon guys! ❤
This is incredible how much one can learn from a single video: computer science, simulation, physics, mathematics. I do not think that the visual explanation or the choice of the words were a huge influence to learning (it is still important). Rather your personality. Trying and failing all the time, but it does not hold you back. In fact, it makes you curious, just as children behave without fear, expectation or worry. Children do stuff because they like it. They love it. They have fun. And you also have these characteristics which make everyone immersed in your work.
As always, good craft!
When the particles settle down you can see multiple different hexagonal lattices forming, and I think that is really cool, because you see those in real life, if you look at galvanised steel those different shades are each their own lattice arrangement that are reflecting light slightly differently and they come from when the zinc coating was still a liquid, and formed those arrangements on the steel surface.
My MSC project back in 1990 was simulating forces in a 3D surface using the Inmos Transputer chip (actually a set of five of them, one controller and four workers). It used a very trivial averaging formula (vertical velocity of cell in next generation is the average of the height differences to its neighbours). It ended up looking quite pretty. After handing the project in, I've barely done anything with computer graphics, sadly. The point of the project was to demonstrate the power of parallelism and message passing rather than accurately model reality.
But your adventure is next level and has got me thinking about downloading a games library for Python and reimplementing my MSc project, then moving onto yours. Thanks for the inspiration.
Thank you for the journey. It was great and satisfying to watch how you handle pretty complex problems of this project.
why does he always sound like he's smiling??
He is 😌
Hahahaha
you're a literal coding code, every upload is just another mind boggling adventure
Having struggled all my life with both math and self confidence, I can honestly say nothing has been more therapeutic, constructive, or productive for me as watching Sabastian's coding videos. With each video of his I watch I shed a little anxiety and think a little clearer. "Let's call this array 'Spatial Lookup' because that sounds nice and fancy"! Brilliant.
New coding adventure: Time to binge watch the whole series again!
It's kind of magical to see it start to look like a real physical thing, when you've seen the math evolve to that point.
I don't know why, but so many points in the video just made me grin. An alternative title to this video could be "The beauty of math".
For every addition you make to the simulation it becomes more captivating and hypnitizing. Watching the initial steps with, what i would call, fairly little math, you can see how its starting to behave water like.
Beautiful video, amazing watch.
I’d love a video on how these animations are made. Beautiful.
I love your videos, mate. It's at the perfect level where I can still follow and covers so many things I want to try doing with Godot.
Also please never stop documenting all the ways your implementations fail, that stuff is *so* relatable - I swear I had point for point the same problems as you when I was doing erosion simulation and actually cackled like a maniac when you too got the spikes forming. 😂
I think this is my favorite video of him so far. Good length, dives into some interesting details, and seems not too complicated to write yourself (disregarding the compute shader part). Also leads to very pleasing visual results. Great work all around.
You can also clearly see convection currents being generated at 46:12 as the boundary volume shrinks, showing that while it probably isn't as realistic as one would like, it is still fairly realistic.
Honestly really interesting video. Much more than I expected from the subject.
I particularly liked it when you started going into spatial indexing with a grid (forget the name of the exact method you picked, but basically same idea as a quadtree except uniform grid-sizes etc) and got into stuff like how to turn it infinite without dynamic quadtrees/lists of cells, etc. Though I also liked watching pretty animations before that, as always (you are truly surprisingly good at them, particularly how you turn "writing code" animations into something that manages to retain attention is surprising. (Honestly, overall I can only compare your animations to 3blue1brown).
beware for an incoming WALL OF TEXT of my ponderances, observations, and impressions, noted down throughout as I watched the video :)
24:00
I was like "of course!" when you mentioned multiplying axes by primes :D Though you should imo have expanded a bit on the hashing, as ie. "3" and "2" are primes (coprime, even), but (2,0) would end up with same hash as (0,3), so explaining what properties/kinds of primes are desired would have been nice. Additionally, there was no mention of the risk of collisions, and *_why_* it is mostly a non-issue (at most you additionally calculate that extra grid-cell unnecessarily literally no change in result - optimization was 'robust'), with any hit on performance being utterly unnoticeable). While I figure it is something rather intuitive if you understand this part, I still think it deserves highlighting for ppl who stumbled because they assumed hashes must be unique, or simply didn't consciously think of this and might appreciate having this fun 'robustness' in the optimization pointed out.
Spatial indexing is honestly such a fascinating subject!
25:00
When you mentioned the sorting, I started further pondering on how the nature of modifications over time play at the sorting algorithms that should be used. Like, I imagine that as the simulation plays only a few particles might change cell at any point, so even if a sorting algorithms worst-case is bad, it might be worth using over others if it handles cases where only a fraction of the list is out of order well. Maybe even ones that require being told _which_ indices has moved out of order.
Would have been nice to have mentions on your thoughts and work on this topic. Or maybe if you decided to not run sort once per frame (that needed it), and instead make Removal and Insertion (aka Modify) operations ensure the list remains sorted? If so, how worthwhile is that to simply running a sort instead, how many particles would need to be out-of-order in a single frame to warrant sorting-per-frame over using a sorted data-structure?
25:50
Not a fan of how you represent start indices here. The infinity values makes sense when you understand what you are doing, but not only does it not truly exist in code (apart from the few languages where it does), but it also implies existence of such a key in the lookup table.
I would much have preferred something like an Option/Result type ("[None, None, Some(0), Some(3), None, ...]"), or if you imagine it risks needing another subject explained, simply use obviously invalid values like "null" or "-1" (I have difficulty ppl watching this video not understanding null values, but negative values is guaranteed to be understood once mentioned how there are no negative indices in a list).
26:00 oh, you did end up explaining collisions. Would much have preferred to see this mentioned back at the hashing section, rather than the very end of spatial indexing.
26:50 so we now see you decided on sorting per frame (I imagine this is best for this many particles). But any thoughts on which algorithm? I know you are using Array's default, but would love to hear any considerations you might have had :)
27:10 I appreciate being shown the hash stuff :) Was curious which primes you would pick, and see you decided on somewhat large ones, as is generally desired for has functions.
28:20 I think it _is_ actually a "somewhat usable solution"? Fairly sure I have heard of "easing in the physics" as being a not too unusual thing to do with simulations, and particularly I have a (very) vague memory of a 2minutepapers video about a liquid simulations where they _did_ "ease in the physics"?
28:40 Why is this so much better? I have some thoughts, but can't feel certain about them and would have loved further indepth explanation on this. Also, would doing something like "position + (predictposition-position)/2" (getting the position between current and predicted) be a further improvement? Or worse?
And does the "step frame-by-frame" work in reverse? Or is this an irreversible process?
30:30 that's interesting behaviour. Any idea why this is, what might have been the issue, and how/what you would need to do to solve it?
Also, damn those are some satisfying animations/simulations to watch, The velocity heat-colors really adds to it :) And vortices looks so good with that!
32:40 I'm noting that the particles seem to like hugging the wall a lot. Unsure why, but I do find it funny as it appears to be an unintentional implementation of surface tension making water like to climb up the sides of a glass slightly. Could you try having a straw of those walls lowered into the fluid to see if there will be capillary action too?
Oh, you kinda mention this later, though not mentioning how this causes that "stick to glass and travel a bit up the side" behaviour.
38:20 Those negative nearpressures actually made for cool effects. I wonder what other fund stuff you could reappropriate this project for if you use that. Maybe something space like? Or like your mold simulations, maybe simply for making cool-looking animations? I also can't help but imagine games taking place in it...
btw, the nearpressure kernel, how can it not mess up the simulation despite having nearly the same radius as the other one, and almost never be less than 50% of it? Or is the smoothingradius secretly much lower for the nearpressure, or the spike spikier than the graph suggests?
40:00 always love your compute shader bloopers :D Look funny, and in a world where we almost only ever see the final results, this kind of thing does really help lower impostor syndrome feelings. We all go through those iterative processes. PS: that one at 40:44 was _really_ cool. Reminded me of something kinda like electricity. Would love to see something more, based on that.
41:00 ooh, another really fascinating subject! Would have loved more indepth on this topic. Also, I imagine you used unit-testing to sanity-check this code? As I imagine trying to figure out it's wrong from looking at a fluid simulation would be difficult :p :D
43:40 ooh, (2 frames of) cool interference patterns at the lower left!!! ...wait ..interference in the velocities? Interesting!
44:40 makes me wish to see the capillary test again, as well as makes me really interested in seeing a siphoning test (does momentum in the fluid make a siphon continue to operate after being started?
In conclusion: really impressed by all you did, learned some stuff, had new questions created, and immensely enjoyed all the mesmerizing animations! :)
Sorting: since adjacent cells are not adjacent in the hash list, moving one object to another cell potentially moving most array entries over by one position. Since the complexity of sorting is just a bit worse (n log n vs n), and there might be many cell transitions per frame, the sorting approach is probably asymptotically optimal.
Why is this so much better?: A big part is that this integration scheme underestimates the kinetic energy of the particles, and that makes them slow down faster. It also has a lower integration error, which is probably good to have in general. Your idea is close to a method that's actually used to improve integration: evaluating the acceleration at start- and endpoint, and taking the average (f(position)+f(position+speed)/2). It's called Heuns method.
As it stands, it is not perfectly reversible, since the original "predictedPositions" estimate is lost. The actual next-step position differs by the acceleration, and since that depends on the predictedPositions, it's exact value is not recoverable. You could however approximate it reasonably well (simply integrate backwards).
that's interesting behaviour: the "intended" bahavior is actually the misestimation of the kinetic energy (making the particles slower than they "should" be, given the high initial compression (it's like a pressure canister explosion)). More steps means lower error -> the slowing down of the particles is replaced by a more "physically correct" simulation.
stick to glass: it's actually a consequence of the density difference between the inside and outside of the box - the particles are "attracted" to (or rather, pushed against it by the liquid) the relative vacuum on the outside (nothing "reflects" the density force from the wall), and slowed down by repeated contact with the wall. Ie. "freezing vacuum walls"...
Walls (or pairs of walls) within the liquid would slow it down (drain energy/speed with each collision), but show no "capillary action", since the water acts across the walls (the missing expected action from "water" on the other side of the wall is what causes the strange behavior).
nearpressures: the nearpressure is very similar to the normal pressure, so if anything, it would just reduce the effective density by a bit (the behavior of a gas is pretty robust concerning different repulsion geometries). Also, the "preferred" distance between the particles was probably already beyond the region where the nearpressure has a significant impact.
You'd expect to see waves in a fluid, and waves do tend to form interference patterns :)
siphon: this simulation has neither air pressure nor significant enough intramolecular attraction (the tendril formation means the liquid has negative surface energy, at least in 2D - ie. you could never siphon bulk water, at most single "strands" of water, and probably only in very weak gravity), nor capillary effects (a side effect of surface energy). So no luck in the current version.
@@sh4dow666
stick to glass: right, thats obvious now that I think about it.
beyond the region where the nearpressure has a significant impact: except they had the same smoothing radius, and almost never less than 50% the amplitude (I think it did at the very fringes of the radius, but even slightly in and the difference is small).
Yes, interference patterns was expected. Except I expected them to appear in the form of density. What was interesting here (aside from simply the "whoa pretty pictures~", which admittedly is something I enjoy with this creators videos) was how they were in the form of velocities instead (I do imagine it comes from the velocity equalization).
siphon: you don't _need_ air-pressure to power a siphon. It is enough that there is a momentum in the liquid (which could manifest from unexpected parts of the implementation - particularly the velocity equalization might provide enough of an adhesive force for a started siphon to continue running. If only for a short while as they probably don't spawn infinite amounts of energy into the system. They also like sticking to eachother as we saw in 43:45, and although this might be caused from the aforementioned, it still does show potentially for forming a band pulling out liquid from the raised reservoir).
Sometimes I don't have a clue what you're talking about but I just like hearing your voice
The editing on this video is on another level!!!
Great job Sebastian 👏
Idea for rendering: You could try to implement the marching cubes algorithm to generate a mesh for it. Since you can already calculate the density at any point in space, this might be pretty straightforward. Marching Cubes is essentially used to approximate a boundary of some sort of single value field, like a density field!
He actually did a video on the marching cubes algorithm once
46:38
@@samuelthecamel that's probably part of why it was brought up
Hmm, the same stuff he did for clouds (taking a noise-field and march cubes over it to generate a mesh) could surely be used for the water-rendering, yeah?
@@theangry0077Raymarching and marching cubes aren't the same thing
crazy how i can watch you do every single step, hear you explain everything so simply and yet the end result feels like magic
like the world is really just made up of math isnt it
Love the 3Blue1Brown plushie cameo. Been looking forward to this video since you first teased it. Though a couple things to note. Firstly, if it wasn't clear, Sebastian is using Freya's "Shapes" asset to draw the circles, which isn't native to Unity. It's a paid asset. (He mentioned that in his video on how he makes these tutorials.) Secondly, it's not really clear to me how the blurring is done, but I suspect that's also a feature of Shapes as well. Would be nice to have Seb confirm or clarify those points.
I would love to know how the density field is drawn. Specially since CPU computing the density for each pixel on screen is not feasible.
Yes!! Was waiting for this one after I had watched Acerola video about ocean simulation and wondered how this fluid simulation project of yours is doing (since you mentioned it back in the AI game challenge). Question answered
A really underrated quality of this sort of basic simulation is it shows how fundamental properties are-stuff like the fluid levels on both sides of a barrier staying even, etc. All a “fluid” needs to have these properties is just the basic density pressure functions, and this is a real physical effect.
I'm a simple gal. I see a new Coding Adventure, I click.
Love these.
I just need to say that I find it very encouraging that you are paying the cat tax up front. I hate it when people have cats, and don't pay the cat tax on their videos.
I know little to nothing about coding and i find your videos absolutely fascinating.
Wait until Sebastian Lague reveals that he used all of his coding adventures to make an actual game
Thank you for including more of your cat in the video. They're the icing on the top of the cake!
Im a developer myself and this video reminded me of how fun coding can be. Definitely subscribing. Thank you for all the work put into this.
42:10 gives me Factorio vibes. Kinda makes sense as a sorter and balancer are related. Never thought of it that way.
hmmm... im not sure if this kind of sorter is always perfectly a balanced when made of splitters in factorio, that would very cool if true
I don't even do programming, but i just love your videos
This reminds me of a game I had on my phone years ago, where it was basically the same 2 dimensional fluid but you could only pick up the fluid. Great video
Hey, physicist with experience in numerics here.
First of all, great stuff! A few comments:
Pretty sure the "prediction" part of the code is only helpful since it effectively makes the particles repel from their own future versions, which in essence means they experience a global damping force - this both explains why it "calms" the dynamics, by being the only mechanism for the system energy to lower (apart from the more realistic damping you added later), and possibly why it depends on the prediction timestep.
I'd recommend just getting rid of this and using only the more realistic damping, unless that doesn't work.
Also, did you try using some other spatial partitions, such as KDTrees? They might be better, though honestly I doubt it.
Another neat option would be to instead of calculating the actual average quantities per particle, calculate a rough scale approximation for the average quantities per cell, and use that for approximating the effects of any far away particles (say, those further that R/3 or so) - this is similar to the Fast multipole method, though for such local interactions which decay quickly it again might just be wasteful.
Oh, and, maybe try some symplectic integration schemes, such as Verlet or even something better (note that even though you have damping forces, which make your system non-Hamiltonian, you could just plug the force directly instead of dV/dq and get nice results) - I didn't mess around with these much, but I've seen claims they greatly improve long term stability for integration (i.e. better conserve energy for the same amount of compute).
Oh, and for the boundary, at least against walls you could treat each wall like a really long and flat particle, manually adding a set density from them to the local density estimate. I don't know how to treat the free boundary "collapsing" though, maybe messing around with the near-repulsion term a little?
on the KDTrees part, i believe he made a small footnote that he might experiment with them which means he likely didnt attempt it, i dunno though, might just be hallucinating
The "prediction" part of the code is actually analogous to the backward Euler method, ie. a more stable numerical integration scheme with less truncation error per step. It would probably be even more stable to use the Heun method (use the average between the current and the extrapolated position), though that would increase the frame time...
((in the specific example in the video, the backward Euler method has the advantage of underestimating the total kinetic energy, while the normal Euler method overestimates it. So if starting off with particles under really high pressure, any kind of energy underestimation probably helps... Simply making the initial packing less dense would be the most elegant solution tho))
Dampening might mask the integration error, but for a realistic simulation it still shouldn't be ignored.
I don't have any practical experience with symplectic integrators, but I'd assume them to be relatively costly computationally, and since we have a dissipative system, they might not actually be much better then Heun/RK4 integration in practice.
The density interpretation doesn't really help my intuition, but I'd guess the reason for the isolated surface layer/tendrils is energetic - ie. surfaces are energetically favorable compared to bulk states at low pressure (or at least a local optimum reinforced by the gravity induced flatness of the surface). I'm really curious whether sufficiently low gravity would cause a 2nd isolated layer to form, or perhaps even dissolve the existing one?
I'd also guess it would be the attractive term, not the near-repulsive one, which is the primary cause of tendril formation in this simulation.
btw, 13:44 shows really nice surface formation in the middle while in zero-G. So getting the gas to form droplets instead of surfaces (minimize surface area, instead of maximizing it) by tweaking the terms definitely seems to be the way to go to prevent tendril formation.
Games aren't like engineering fluid dynamics so I disagree about the prediction part. The state of the art for real time fluids is actually to get rid of SPH, leaving only the density computation, and instead solve the particles via constraints via newton's method. Of course with newton's method you'll make an even more crude prediction and then adjust multiple times per time step, which leads to even worse global damping (solved via introducing aritifical constraints)
Yes, this is nothing like what a physcists would do, but this is computer graphics, not physics. The position based constraints give nearly identical visuals but performs much better for a wider range of time steps, and is less susceptible to tensile instability.
@@sh4dow666 I'm making my own video, but it will have all the steps: simulating, rendering, external object interaction, and control (turning water into the shape of meshes and animating them).
The integrator isn't the issue here imo. The real issue is the way the simulation is being solved via SPH, when it's more efficient and stable to solve via density constraints alone. Which is pretty obvious during the video once he runs into incompressibility issues (common flaw of standard SPH).
@@UnigmaThe question is whether this is primarily supposed to be a physical or graphical fluid simulation :)
Those moments when things suddenly look sort of realistic the first time are just 💆
amazing man; way to go; I can't wait to see the future video; more videos on fluids are always welcome!
For my masters thesis I have actually used your Marching Cubes algorithm from the Terraforming video to render a fluid amongst other methods of rendering. Raymarching was one rendering technique I gave up on due to the limited time I have for the thesis. Allthough I would love you see your spin on it at a later point.
That’s awesome! What other methods did you look at? I guess one could blur the particles, it struggling to think of anything else to try beyond that.
I looked at the Screen Space Meshing Paper from Matthias Müller which creates a new Mesh every frame that fits the viewport frustums view of the Particles and am currently stitching together some old Nvidia Papers for direct rendering as basically a post process shader by rendering the Particles into a depth buffer, smoothing that, creating normals from that depth map and then shading that. Was a GDC 2010 talk named "Screen Space Fluid Rendering for Games" by Simon Green. It compliments well with another paper from Simon Green called "Screen space fluid rendering with curvature flow".
@@Christanoid Nice, I'll look into those -- thank you :)