I had no idea what you were talking about most of the time but the video was still insanely enjoyable! Your voice and music choice makes it even better, love it!
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 :)
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
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
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.
@@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
@@practicemodebutton7559it’s suppossed to be a joke about how every person that solves a problem dosent get recognition and instead the second person that does
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.
Could you calculate pressure for each cell in order to modify the velocity? Pressure will want to equalize, killing the velocity in the system. Velocity will change the pressure. And so on. Kinda like you solve Navier-Stokes equations in FVM. I now kinda want to try it myself xD Great video, thanks!
I had found a really interesting video where this guy wanted to make a simple river water simulation, then explained the entire history of fluid simulation, along with the pros and cons of both techniques, and the limitations, talked about combining them, touched on Avatar 2 near the end to get a cryptic explanation of the Houdini fluid simulation, and finally ends his video by adding white water particles to his river simulation. AND I CANNOT FIND THIS VIDEO, like I'm not smart enough to know all the stuff I know about fluid simulations without having watched that video, but I can't find it anywhere. Please help, anyone.
If that is what you mean, there is a lambda parameter to the RenderingArrows shader here github.com/hughperkins/UnityFluidSim-pub/blob/67a431c53f8328818ef6d2fcbab2fffd5e7a87ba/Assets/LiquidShader/Resources/LiquidShader/RenderingArrows.compute#L17
(and htis is basically used to add a vector equal to the length of the arrow here, multiplied by the lambda,github.com/hughperkins/UnityFluidSim-pub/blob/67a431c53f8328818ef6d2fcbab2fffd5e7a87ba/Assets/LiquidShader/Resources/LiquidShader/RenderingArrows.compute#L60, which allows the lambda to slide the arrow backwards and forwards along its length
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.
Hello RL HUGH. That's indeed a very good explanation of fluid simulation. You mentioned that you spent some time understanding the math behind fluid dynamics like PDEs... It is the same to me now, I am a new researcher in fluid dynamics. I want to know how long you did it take you to understand math? How was your road map to learn it, could you share it with me?
The sources I mentioned in the video were my main resources really. I made a log as I was going along docs.google.com/document/d/1QXPJd5mk8O5eHbFklC8w2AwL8LLZmLx61ybfPBETM1s/edit?usp=sharing There's a paragraph half way down page 17 on the things I studied. If you want me to share out pde.ipynb and fluid_simulation_maths.md I can probably do that. They're very terse though, lacking explanations.
@@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?
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
the limitation from the threading seams to be a problem. i don't know the tool you use, but try to remove this limitation would probably be a big improvement. (and 1 thread per cell ? isn't it very ineffective because too mush thread ?)
@@rlhugh "limitation i am referring to" : things like not be able to update all at the same time. "GPUs looovvveee threads" but probably not to the point of wanting to manage one millions of them if you want to try to do 1000x1000 "pixel".
the universe is a fluid, despite the intention to suppress this as a concept by relabeling it as just space, spacetime, vacuum, quantum field, etc. Magnetic fields mechanical are pressure gradients in the fluid that fills space. Motion in any fluid creates toroidal fields that look like magnetic fields, because they are the result of fluid dynamics alone. Electrical charge is just pressure inside the eather that fills space. Fluid flows according to the vectors length and direction, which equate to pressure strength and force / flow direction. It's just a simpler way to model fluid flow, sort of like a reduced way. If you insert particles and make them move according to the force vectors, you get a normal particle based fluid simulation. If you just show the vectors and color their grids, you have a low resolution fluid simulation like any other, it's just less detailed / granular and approximated, but still real.
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?
@@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
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?
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! 🙌
Ya and we took pictures of celebrities feet and sent them to other people with it
Trvke
very good video. i'm glad you showed or mentioned what approaches didn't work
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,
Great work, I can't wait to see your next simulations!
I had no idea what you were talking about most of the time but the video was still insanely enjoyable! Your voice and music choice makes it even better, love it!
Thank you!
Looking at these arrows, I realized that this is an ideal simulation of electromagnetic waves.
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 :)
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 :)
Really well produced, nice work
I wish the very best on TH-cam, I am so glad I discovered your channel. Keep up the good work !
Great video, very helpful for a project I'm working on that needs some kind of ocean currents simulation.
Dawg go grt your Masters, this could be a Masters level project
lol, thanks! :)
After the earth, sun and black holes could you also simulate my room too hahahah Great video and a very cool idea! Keep up the great work
This is an amazing explanation of CFD, thank you!
Can't believe I watched entire video about coding and didn't get bored
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!
I love this, thank you for makin my day on yt much better!
Thank you very much!
Fantastic video! ❤
educational and entertaining! loved it, thank you
Thank you!
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!
Great and inspiring video, thanks a lot!
This is super cool, keep it up!
Thank you!
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 :)
You could have used MultiGrid for the solver since it land it self to parallelism better
Yes. Potentially a topic for a next video :)
Subbing cause I wanna see you simulate the inside of Earth. Great content
This guy's gonna love learning about the weak fem form for the constitutive eularian fluid equations
Good heads-up. Thanks!
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.
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
Got recommended.....now in love
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)
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
@@practicemodebutton7559it’s suppossed to be a joke about how every person that solves a problem dosent get recognition and instead the second person that does
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.
Could you calculate pressure for each cell in order to modify the velocity? Pressure will want to equalize, killing the velocity in the system. Velocity will change the pressure. And so on. Kinda like you solve Navier-Stokes equations in FVM. I now kinda want to try it myself xD Great video, thanks!
@@mmheti yeah, you can. There's a few different approaches possible. They each have their own good and bad points.
no links to the code?
Published to github.com/hughperkins/UnityFluidSim-pub
@@rlhugh thanks.
I had found a really interesting video where this guy wanted to make a simple river water simulation, then explained the entire history of fluid simulation, along with the pros and cons of both techniques, and the limitations, talked about combining them, touched on Avatar 2 near the end to get a cryptic explanation of the Houdini fluid simulation, and finally ends his video by adding white water particles to his river simulation. AND I CANNOT FIND THIS VIDEO, like I'm not smart enough to know all the stuff I know about fluid simulations without having watched that video, but I can't find it anywhere. Please help, anyone.
how about adding damping?
How do you transform the vectors that are centered into the lateral vectors and vice versa
Do you mean, from the point of view of animations for this video, or ... ?
If that is what you mean, there is a lambda parameter to the RenderingArrows shader here github.com/hughperkins/UnityFluidSim-pub/blob/67a431c53f8328818ef6d2fcbab2fffd5e7a87ba/Assets/LiquidShader/Resources/LiquidShader/RenderingArrows.compute#L17
(and htis is basically used to add a vector equal to the length of the arrow here, multiplied by the lambda,github.com/hughperkins/UnityFluidSim-pub/blob/67a431c53f8328818ef6d2fcbab2fffd5e7a87ba/Assets/LiquidShader/Resources/LiquidShader/RenderingArrows.compute#L60, which allows the lambda to slide the arrow backwards and forwards along its length
Thanks for the beautiful video.
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
Thanks for the explanations and the sources! please add the links to the description though :D
Published to github.com/hughperkins/UnityFluidSim-pub
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 🤔
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! :)
Hello RL HUGH. That's indeed a very good explanation of fluid simulation. You mentioned that you spent some time understanding the math behind fluid dynamics like PDEs... It is the same to me now, I am a new researcher in fluid dynamics. I want to know how long you did it take you to understand math? How was your road map to learn it, could you share it with me?
The sources I mentioned in the video were my main resources really. I made a log as I was going along docs.google.com/document/d/1QXPJd5mk8O5eHbFklC8w2AwL8LLZmLx61ybfPBETM1s/edit?usp=sharing There's a paragraph half way down page 17 on the things I studied. If you want me to share out pde.ipynb and fluid_simulation_maths.md I can probably do that. They're very terse though, lacking explanations.
Awesome 👍
Thank you!
Thank you for this video
Thank you!
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
the limitation from the threading seams to be a problem.
i don't know the tool you use, but try to remove this limitation would probably be a big improvement.
(and 1 thread per cell ? isn't it very ineffective because too mush thread ?)
What limitation are you referring to, concretely? Note that this is running as a shader, on a GPU. GPUs looovvveee threads.
@@rlhugh "limitation i am referring to" : things like not be able to update all at the same time.
"GPUs looovvveee threads" but probably not to the point of wanting to manage one millions of them if you want to try to do 1000x1000 "pixel".
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 :)
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
5:07 project gauss seidel wait tahts the ROBLOX physics engine!
Not sure I follow. Do you mean that roblox uses fluid simulation?
Beautiful!
so good
Great video
wait you need a macbook pro to do pro stuff?? (looks sexy)
I'm using a MacBook air m2
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
11:11 that looks like the lines of a magnet.
More like a magnetic field simulation than a fluid simulation, is my impression.
the universe is a fluid, despite the intention to suppress this as a concept by relabeling it as just space, spacetime, vacuum, quantum field, etc.
Magnetic fields mechanical are pressure gradients in the fluid that fills space. Motion in any fluid creates toroidal fields that look like magnetic fields, because they are the result of fluid dynamics alone. Electrical charge is just pressure inside the eather that fills space.
Fluid flows according to the vectors length and direction, which equate to pressure strength and force / flow direction. It's just a simpler way to model fluid flow, sort of like a reduced way. If you insert particles and make them move according to the force vectors, you get a normal particle based fluid simulation. If you just show the vectors and color their grids, you have a low resolution fluid simulation like any other, it's just less detailed / granular and approximated, but still real.
this is so cool, is it possible to upload the source code to a public repo?
Published to github.com/hughperkins/UnityFluidSim-pub
Nice
Thank you!
Cool
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
this is very interesting! subs++;
Now I have to find someone to explain how to do that in Godot
Very nice video. Now get a beefy graphics card and run at very high resolutions lol.
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...?
this thumbnail is better
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?
"shaders are fun" consider me an opp
Haha :)
Ъ.
I am trying to simulate aerodynamics of stl files in 3D space. But I haven't made it yet. Who can do such a thing?
Interesting idea. Do you have any example files?
@@rlhugh m a v . i s t / F L u i d
@@rlhugh I can't add it here, youtube deleted it. I wrote it in the description of my channel