Real-time Eulerian fluid simulation on a Macbook Air, using GPU shaders
Vložit
- čas přidán 25. 12. 2023
- In order to implement fluid simulation we need to implement conservation of mass, incompressibility, and conservation of momentum. How to do this, using Eulerian cell representation, on GPU shaders?
Update: I'm dabbling in creating a discord server at / discord Please feel free to join :)
Update 2: source-code available at github.com/hughperkins/UnityF... - Věda a technologie
That was one of the best explanations for advection I've seen online! Especially the pushing bubbles out of a phone screen protector analogy.
Thank you very much! Very much appreciated :)
videos like these are what internet was made for
Wow, thank you very much! 🙌
I understood none of this yet I was glued to it all the way through
Haha, nice :)
Hugh, the standard first book on PDE is Walter Strauss's book. If you want to try questions on me I'm happy to help out.
love the experimental feel to how you moved forward itteration by itteration,
loved the video! feels like discovering sebastian lagues yt channel all over again :)
Wow, that's a very nice thing to say. I feel like I can die happy now. I mean, unfortunately this is my least bad video to date, and you will be disappointed if you watch any of my others, but it's still very nice to hear these words :)
very good video. i'm glad you showed or mentioned what approaches didn't work
Great work, I can't wait to see your next simulations!
This is so cool, and you did a great job with the video editing! I hope you make more videos like this!
Thank you! That's very kind to say. Very much appreciated :)
Can't believe I watched entire video about coding and didn't get bored
imagine putting a few ai's in there, make them evolve, adapt to the environment and make them learn how to utilise it to its advantage
Interesting idea 🤔
I wish the very best on CZcams, I am so glad I discovered your channel. Keep up the good work !
Really well produced, nice work
In a way, this is functionally simulating Quantum Mechanics and illustrating the principle of "Particle/Wave duality". The entire fluid motion can be represented as a vector. But the vector, *itself,* must behave as a particle, moving in response to the overall "equation" of the fluid flow. And that flow, in turn, changes in response to how those velocities keep changing within it. The more "interactions" there are, the more you'd have to "zoom in" and re-calculate based on the rapidly changing velocities. But the fewer the interactions, whether that be due to smooth flow, "low temperatures" (less movement), etc., the more you can just look at the overall average equation for how the vectors evolve.
So, in keeping with this notion that this is very much like Quantum Mechanics, using the principles of QM would probably help improve the quality of the simulation.
*1)* Non-Zero Baseline: In QM, particularly Quantum Field Theory, one of the major notions is that everything isn't sitting at a baseline _zero_ state. Rather, there's a certain minimum baseline energy already present, and it's the net _difference_ over *or under* that baseline which is considered. To put it in context of a fluid, since we're discussing fluid dynamics, it's like there's a big ocean of energy already sitting there. How deep that ocean is is a question scientists argue over endlessly, but it's what happens at the surface that is actually important and what they more or less agree on.
*2)* Constant Activity: There are constant "little ripples" going all over the place. The surface of the ocean isn't still; it's always churning and bubbling and mixing; and as those little micro-waves this motion generates interact with one another, the peaks of the waves amplify one another, the dips amplify one another, but where peak and dip meet they cancel out. And when it churns enough, it gets big enough to be called a true "wave" (a particle like an electron or a quark). You can't really say that an ocean wave has one specific location; it's a "part" of the ocean as a whole. But you could also point at a part of the ocean at any given time and ask, "Is this currently part of a wave?" Maybe yes, maybe no. The bigger and stronger the wave, the more likely you'll be to "catch" it.
*3)* Quantized: This means that a wave can't be an arbitrary "height" in this ocean (where "height" here is a stand-in term for the "energy" of a particle). It would be as if waves can only be increments of 10 meters in height. Anything between 10 meters below the surface and 10 meters above the surface would effectively register as if it were right at the surface. Functionally, what this is is "statistical rounding". If there were a wave (particle) that could potentially be 17 meters tall according to the vector math, the particle math has no clue what that means. Particle math only deals in increments of 10 meters. So it has to round 17 meters; but it doesn't use formal rounding. Instead, it uses statistical, trigonometric rounding. 17 meters is 0.7 of the way from 10 to 20. I forget the exact formula, but it's 50/50 if it were X.5, but more than a mere 70% chance at X.7 to round up to the higher value (it follows trigonometric values around a unit circle).
So these aspects could possibly be implemented in the following ways. First, have some non-zero "baseline" flow value. Never have "zero flow". Not zero *actual* flow, anyway. But simulate the actual pertinent _movement_ not based on this "real baseline" but, rather, relative value compared to that baseline. So, for example, if baseline flow has a vector weight of, lets say, 100, your actual fluid movement model *treats* 100 as if it were zero (staying still), and then movement of 105 is going 5 _faster_ than that. Next, have micro-purturbation in the model by allowing that baseline value to "jitter". While baseline flow that's considered "stillness" would still be considered 100, any specific "cell" of fluid would randomly, iteration to iteration, have a value between 98-102. And it can change its value by up to 2 either positive or negative. These will still factor into calculations, so these changes won't "come from nowhere"; if micro-flow is generated, it will pull from surrounding cells. Lastly, when it comes to evaluating how the vectors, themselves move, you can "fudge" the value a bit. Round it based on the statistical rounding I described to let it "zoom out" and use lower resolution, and then do more of a "random step" pattern instead of a complete vector calculation to determine how a vector moves. This way, vectors don't have to consider, "how am I moving based on everything around me" 100 times, they just have to decide, "how likely is it for me to move up, down, left, or right based on forces around me" 100 times.
Interesting. Thanks! :)
Great and inspiring video, thanks a lot!
first thing I thought about when I clicked on this video is about The Powder Toy which is a pixel based particle simulator game which actually has that exact same type of fluid simulation for simulating air in the game
Interesting! Thank you!
Thanks for the beautiful video.
I love this, thank you for makin my day on yt much better!
Thank you very much!
I loved this video! Really inspiring, and I'm sort of amazed that this was running on a macbook air too - great job :D Thanks so much for sharing.
Thank you very much!
This is super cool, keep it up!
Thank you!
This guy's gonna love learning about the weak fem form for the constitutive eularian fluid equations
Good heads-up. Thanks!
educational and entertaining! loved it, thank you
Thank you!
Subbing cause I wanna see you simulate the inside of Earth. Great content
Beautiful!
You could have used MultiGrid for the solver since it land it self to parallelism better
Yes. Potentially a topic for a next video :)
i bet this would run much better on a gpu with a cooling system and more than 10 cores (or whatever your model of macbook has)
Got recommended.....now in love
Great video
No way Euler got named for a fluid dynamics problem. We're supposed to name the problem after the *second* person to solve it!
nah he can keep it
Thank you for this video
Thank you!
Awesome 👍
Thank you!
Thanks for the explanations and the sources! please add the links to the description though :D
Published to github.com/hughperkins/UnityFluidSim-pub
me: 50 frames per second that’s pretty bad performance
RL: *”on my MacBook Air”*
thats CRAZY
50 fps is bad?
@@D.S69 for a 480p 2d fluid simulation on a GPU, yes, but I'm used to these videos being done on NVIDIA cards like 3080s with tens of thousands of cores. Having this kind of performance on a MacBook Air (limited power with no active cooling), especially *while recording* is really awesome
Cool
Would it be possible to create a more complex velocity map by uploading an image, and only looking at hue and brightness, ignoring saturation? Obviously colors approaching white could be a problem, but you could remedy this by thresholding saturation and then treating anything below the threshold as a non-fluid/wall if the brightness is high enough that it would otherwise have a velocity
Good idea! It's open source. PRs welcome :)
Nice
Thank you!
Imagine the kind of simulation you could do with a 4090 over the mac book.
No no no you dont understand plebian
Apple Silicon tm is magic and cannot be beaten by mere mortal technology
no links to the code?
Published to github.com/hughperkins/UnityFluidSim-pub
@@rlhugh thanks.
Now I have to find someone to explain how to do that in Godot
regarding the parallel part: would it be feasible to work the opposite way? Instead of writing to 4 cells, each cell would instead read from 4 neighbors and update itself.
No, because we are writing to the walls of the cells, not the cells themselves. And each wall has two neighbors.
thanks so much all the other videos about water simulation is either way too complicated or just a blender tutorial
Awesome. Thank you very much :) that's very kind to say. I really appreciate your saying that :)
11:11 that looks like the lines of a magnet.
So persistent zero velocity is like a solid object? I wish it were easier to see it against an unmoving background .
Yes, that's right. As far as the coloring scheme, definitely open to suggestions. Won't affect this video, since cannot modify published videos. But could be useful for future videos.
this thumbnail is better
do you think this could be used for electromagetics?
Interesting question!
Depending on what you want. I guess you want to iteratively compute the EM fields?
Some of the simulations definitely looked like simple 2d magnetic fields
Could write conflicts also be avoided by just writing to a separate buffer fhan the one you are reading from?
No, because we are writing to the walls of the cells, not the cells themselves. And every wall has two neighbors, so there would be conflicts.
@@rlhugh Thank you. How would you write the shader to allow for each pass to be offset correctly. Do you pass a uniform that specifies the offset? And are you still running multiple iterations for each of the four divergence passes?
For your first question, yes, that's right. I simply pass in two ints, one for x offset (0 or 1), and one for y offset (0 or 1)
As far as your question about 'divergence passes'. we have to re-compute the divergence for each of these sub-passes. The divergence was modified by the previous sub-pass, and we need to take that into account. (if we didn't need to recalculate divergence, we would only need a single pass, no sub-passes).
Oh, I misunderstood your second question. So yeah, you do each of the 4 sub passes. Let's call that one pass. then iterate over the pass of 4 sub passes, like 200 times or so
This is really cool. Do you have a github repo available for this?
I probably should do that yeah...
Published to github.com/hughperkins/UnityFluidSim-pub
whoops, forgot to set it to 'public'. Fixed. hopefully
this is so cool, is it possible to upload the source code to a public repo?
Published to github.com/hughperkins/UnityFluidSim-pub
How do you run these shader ? Can it use under sdl2?
These are running in Unity, using HLSL.
wait you need a macbook pro to do pro stuff?? (looks sexy)
I'm using a MacBook air m2
Very nice video. Now get a beefy graphics card and run at very high resolutions lol.
Which method is cheaper to run?
You mean for Lagrangian vs Eulerian? Eulerian is faster/cheaper.
@@rlhugh Sorry for the vagueness, I meant for particle - vs vector based
Love this but if that’s how you say Euler I’ve been saying it wrong all this time 💀💀
I did research the pronunciation. There are a couple of ways. Before I researched the pronunciation, I was saying "you lurr Ian". But "oiler Ian" appeared to be more common, as far as I could see? How are you thinking if should be pronounced?
@@rlhugh I’ve been saying youll-lah 😅
@@tomd6410 actuuaaalllyyy seems that it might depend on us vs UK pronunciation, eg see youglish.com/pronounce/eulerian/english/uk
@@tomd6410i feel like "name"-ian in English are pronounced very differently from how you pronounce the name so while Euler is pronounced weirdly, eulerian is pronounced how you would expect, like Laplace and Laplacian
Oy-lear-ean, surely...?
"shaders are fun" consider me an opp
Haha :)
rather than updating a bunch of nonadjacent cells why don't you store two buffers, and instead of changing a cell's neighbors, instead calculate how a cell is affected by its neighbors, and write that into the second buffer.
Do you mean, in the projection step? Because we aren't updating the cells: we are updating the walls of each cell. And each wall is attached to two cells. There isn't a way of updating one cell without updating its neigbor, because we aren't really updating the cells: we are updating the walls. When we choose 'a cell', what we are doing is updating all 4 walls of that cell. Then, you might say, can we select arbitrary walls? Well, no, because the update of 4 walls around a cell is based on ensuring incompressiblity of the fluid entering and leaving that one cell, but the updates themselves are applied to the walls, not to the cell. There is no way then to update two adjacent cells, because we'd be updating the same wall twice, i.e. the wall in between the two cells. Having a buffer doesn't really change that. Let's imagine we update the walls around cell A, into buffer 2. Now, when we calculate the walls around adjacent cell B, we'll need to read the values from buffer 2, in order to have the up to date value for the shared cell wall. So, it's sequential, not parallel. Not sure to what extent that answers your question?