Fluid Simulation(kyndinfo.notion.site)
kyndinfo.notion.site
Fluid Simulation
https://kyndinfo.notion.site/Fluid-Simulation-f0516d9d12e245a08ae5c7545ac822dd
15 comments
Extremely impressive, and VERY well explained. I can't overemphasize how much I wish there were way more stuff like this online. I also really like something about having the English and Japanese text right next to each other... maybe it's just the visual reminder that there's so much more internet outside of the English-speaking bubble.
This topic is about fluid simulation, but it also references shaders as a way to performantly implement fluid simulation.
I've played around with shaders in the past to build particle simulations with millions of points, and it's always really tickled my mind. You basically write functions that operate against a big 2d grid of colors. But because colors are represented by a 4x1 vector [r,g,b,a], you can repurpose this pattern to do general purpose computation (e.g. you can represent a point in a 3D coordinate space as a [r,g,b] color).
You can see this in the codepen in this post. It's literally creating "materials" and "render targets" that are actually just intermediate computation steps in the fluid simulation.
I've played around with shaders in the past to build particle simulations with millions of points, and it's always really tickled my mind. You basically write functions that operate against a big 2d grid of colors. But because colors are represented by a 4x1 vector [r,g,b,a], you can repurpose this pattern to do general purpose computation (e.g. you can represent a point in a 3D coordinate space as a [r,g,b] color).
You can see this in the codepen in this post. It's literally creating "materials" and "render targets" that are actually just intermediate computation steps in the fluid simulation.
class Fluid {
constructor(context) {
this.context = context;
this.speed = 4;
this.forceInitMaterial = this.createShaderMaterial(forceInitFrag);
this.divergenceMaterial = this.createShaderMaterial(divergenceFrag);
...
this.divergence = this.createRenderTarget();
this.advection = this.createRenderTarget();
...that's pretty much how CUDA was born 15 years ago. Crazy how a few guys playing with shaders to simulate clouds led to the AI craze we have today.
Look up Mark Harris PhD thesis "Real-Time Cloud Simulation and Rendering" for more details.
Look up Mark Harris PhD thesis "Real-Time Cloud Simulation and Rendering" for more details.
I'm sure the origins of CUDA are very interesting in their own right, and it cannot be denied that the evolution of the GPU and GPU programming has had a huge impact on the growth of the field.. but, without the specific work of these specific people, at worst I think we'd only be a tiny bit behind where we are now.
The AI craze we have today is built on the continuous, sustained work of a huge amount of people over years and years.
The AI craze we have today is built on the continuous, sustained work of a huge amount of people over years and years.
yes, of course. I think this holds for pretty much all major inventions, which are attributed to single persons.
At some point in time, certain ideas are just inevitable. I'm certain back then many people were looking at GPUs and tricked them into performing non-graphics tasks.
At some point in time, certain ideas are just inevitable. I'm certain back then many people were looking at GPUs and tricked them into performing non-graphics tasks.
Wow, besides this fluid simulation note the site has a ton of discussion of other topics. I love to see personal notes wikis like this.
https://kyndinfo.notion.site/Sketching-with-Math-and-Quasi-P...
https://kyndinfo.notion.site/Sketching-with-Math-and-Quasi-P...
I once wrote a lava lamp thingy back in school when we were toying with 16bit C++ and 32bit assembly to get some nice demos on an mcga screen. It looks a bit like this but it was not a simulation we used three different buffers with pictures containing balls that we xor-ed over each other while the layers were moving in different directions using sin/cos functions.
>"First, we will define the space as a grid of cells. We want to smoothly move paints, or different colors, around in this space. To do this, we will use two maps, specifically two 2D arrays, to capture the information for each cell. The color map stores the color values of each cell, while the velocity map stores a vector that represents the velocity, i.e. the information about the speed and direction of the water flow in each cell."
First of all, great article!
Second, there's something weird-but-interesting going on in the quote I've highlighted, above...
First, we have Conway's Game Of Life:
https://en.wikipedia.org/wiki/Conway's_Game_of_Life
To recap, Conway's Game Of Life is sort of like a one array (representing the screen), 2D simulation.
Whereas the above fluid simulation uses two arrays, two maps, in 2D...
My question, my curiosity, is simply this:
What would happen if we used three or more arrays, three or more maps, in 2D?
Like, n-maps, n-arrays (the "higher dimensional generalization" if you will...) to represent things other than velocity...
What would our simulation look like, then?
For example, some interesting things to play with, in this space, might include (but not be limited to, as Lawyers would say!): Acceleration, Jerk, Snap, Crackle and/or Pop:
https://en.wikipedia.org/wiki/Fourth,_fifth,_and_sixth_deriv...
Basically, if velocity is the first derivative of position (and thus should go in the second (n+1) array or map), then maybe other derivatives can go in the higher dimensional map appropriate to them.
Oh sure, they could be computed on-the-fly too... but that's no fun!
In fact, what might be interesting might be to see side-by-side graphics of higher-dimensional maps along with the base-level map, as the simulation (be it Life or Fluid Dynamics or ?) evolves!
What could be discovered?
Well, I as-of-yet don't know obviously... but it seems like these concepts should mesh together somehow...
Anyway, great article!
First of all, great article!
Second, there's something weird-but-interesting going on in the quote I've highlighted, above...
First, we have Conway's Game Of Life:
https://en.wikipedia.org/wiki/Conway's_Game_of_Life
To recap, Conway's Game Of Life is sort of like a one array (representing the screen), 2D simulation.
Whereas the above fluid simulation uses two arrays, two maps, in 2D...
My question, my curiosity, is simply this:
What would happen if we used three or more arrays, three or more maps, in 2D?
Like, n-maps, n-arrays (the "higher dimensional generalization" if you will...) to represent things other than velocity...
What would our simulation look like, then?
For example, some interesting things to play with, in this space, might include (but not be limited to, as Lawyers would say!): Acceleration, Jerk, Snap, Crackle and/or Pop:
https://en.wikipedia.org/wiki/Fourth,_fifth,_and_sixth_deriv...
Basically, if velocity is the first derivative of position (and thus should go in the second (n+1) array or map), then maybe other derivatives can go in the higher dimensional map appropriate to them.
Oh sure, they could be computed on-the-fly too... but that's no fun!
In fact, what might be interesting might be to see side-by-side graphics of higher-dimensional maps along with the base-level map, as the simulation (be it Life or Fluid Dynamics or ?) evolves!
What could be discovered?
Well, I as-of-yet don't know obviously... but it seems like these concepts should mesh together somehow...
Anyway, great article!
Fluids -- very demanding mech engineer course. I understand why now.
Also --> those simulations would be pretty sweet screen savers :)
Also --> those simulations would be pretty sweet screen savers :)
Does this rely on the Navier-Stokes theory?
[deleted]
Marvelous work! I'm just starting to familiarize myself with CFD/OpenFOAM in a CAD/CAM context,and it's sometimes remarkable how compact and elegant the math can occasionally be.
I'm reminded of the occasional notion in cosmology that many mysteries of existence go away if you regard spatial dimensions as emergent phenomenon arising from deeper quantum "degrees of freedom". It makes me think of ancient assumptions - atomos, Arunic kana - that there is a thing - a space, a volume - too small to cut into. But doesn't that seem a little contrived? How can something be too small to divide? I'd propose they're coming at it from the wrong way. It's not the space, it's the fact that it can't be cut any more. The system's freedom of action restricted to a single vector - the future can be constrained no further - and subsequent knife cuts do nothing. The sum of these qualities in maco systems thus, in our minds, resolve into width, depth, length.
Similarly, stack up the CFD stuff fine enough and dense enough, and you get FEA emerging. Now, I'm . . ok, keep in mind I am a layman in absolutely everything . . but it seems like a not-horrible metaphor.
I'm reminded of the occasional notion in cosmology that many mysteries of existence go away if you regard spatial dimensions as emergent phenomenon arising from deeper quantum "degrees of freedom". It makes me think of ancient assumptions - atomos, Arunic kana - that there is a thing - a space, a volume - too small to cut into. But doesn't that seem a little contrived? How can something be too small to divide? I'd propose they're coming at it from the wrong way. It's not the space, it's the fact that it can't be cut any more. The system's freedom of action restricted to a single vector - the future can be constrained no further - and subsequent knife cuts do nothing. The sum of these qualities in maco systems thus, in our minds, resolve into width, depth, length.
Similarly, stack up the CFD stuff fine enough and dense enough, and you get FEA emerging. Now, I'm . . ok, keep in mind I am a layman in absolutely everything . . but it seems like a not-horrible metaphor.
[deleted]