Fluid Simulation (opens in new tab)

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.

  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();
          ...

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...

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!

Fluids -- very demanding mech engineer course. I understand why now.

Also --> those simulations would be pretty sweet screen savers :)

Beautiful

Does this rely on the Navier-Stokes theory?

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.