Riel's Experiments in Simulation

Whoof. This one took a while. The idea was to get the system working with a variety of possible data structures for speed and ease of access, which meant either rewriting a lot of code or finding a general way to deal with multiple types and array dimensions. Luckily I found a happy medium.

For a good few days the simulation just wasn’t running. That sucked. There’s nothing worse than getting no results, especially with an engine with as many visual tools as Unity. Finally, after a bunch of debugging, I found the central problem (a ‘!=‘ where there should’ve been a ‘==‘ was preventing the simulation from even running each frame) and... well, I got this.

Which is nice and good and fun but not what I want. Is this a space worth exploring? Only as an exploration of glitches, specifically, I think. Most people are familiar with that explosive rise.

Turns out this is a result of a failure to average. The difference between

   M = (a + b + c + d) / 4  -  x

and

   N = a + b + c + d  -  4 * x

is that, while N = M as long as x isn’t zero, N = 4 * M when x is zero. Here:

   M(x = 0) = (a + b + c + d) / 4  -  0

   N(x = 0) = (a + b + c + d) - 0

   => N = 4 * M

Unfortunately that step was a key part of my algorithm* and, yet more unfortunately, most of the points had an initial height of zero. Once I figured this out, though, and applied a nice blue shader... Well. It worked just fine.

So fine, in fact, that I can run a 100x100 grid in the editor with no slowdown.

I figured out part of the problem with slowdown: I was looking at the results of the simulator in the editor, which, according to the profiler adds

a lot

of overhead.

Yeah. About half a second’s worth per frame with 10,000 cells. Luckily, even in the editor, this simulator works great!

After a little finagling I was able to lift out some of the parameters and make them visible in the unity editor. Now I can make the simulation move in slow motion:

And dissipate really quickly:

And, yes, do both at the same time:

(I’ve actually fixed this so the dissipation is related to the speed of the simulation. It should disappear quite that quickly.)

Next step is to code a general way to change the velocities and positions of the fluid cells. I want to make raindrops! After that, I want to add solid-fluid coupling (may be tougher than it seems...), and after that... well, we’ll see, but I think I’d like to try some more complicated realtime algorithms. Something that can generate a cresting wave would be nice.

For fun, here's a really crazy wave in slow motion. If you have any questions, feel free to ask!

The idea of a heightmap is that rather than simulating the full volume of a fluid you only simulate its surface. Each cell on the horizontal grid represents a column of fluid. This particular algorithm is very simple: every timestep, each cell averages the heights of its adjacent cells, subtracts its own, and sets that number as its rate of height change. Basically, if a cell is lower than its neighbors, its height will increase; if a cell is higher than its neighbors, its height will decrease. Unity-wise, I just have a bunch of stretched-out cubes and every frame I set their vertical position to the height of the corresponding cell in the algorithm (which is why the wave pattern is replicated on the top and bottom). The algorithm runs every frame.

Now that I’ve sufficiently bored you, here’s some more videos:

This grid has a higher resolution, 100 cells to a side rather than 41. Of course, because it's a big square, that means there's 10,000 cells rather than 1,681 cells, and that's enough of a difference to cause a slowdown. Without the capture software the mid-resolution simulation runs smoothly, but the high-resolution one judders a little either way.

Part of the reason it's slow is just the larger quantity of cells; because the cells only check their neighbors' heights, the height "signal" can only travel one cell per frame, so even between frames was constant it would still take twice as long for the ripple to reach the edge. But the time between frames also increases because there are 5 times as many things to do.

I'll admit I'm a little disappointed. This was the simplest possible algorithm and it gets slow at only 10,000 cells. I want to get into much more realistic--and more complicated--realtime simulation. That sort of thing does exist, though, so all this really means is my implementation is bad. It was even slower at first--"unrolling" some boundary-checking and being smart about my for loops sped it up a lot. I'm sure there's more code optimization to be done. Furthermore, I'm not exactly a master of Unity--I'm sure there's much better ways to process and render fluids than re-assigning the position of thousands of transforms every frame. In fact, I'm currently working on replacing all the cubes with a single mesh, which should hopefully be faster. I'd love to use shaders, eventually, but that gets complicated quickly and I don't know how much interaction I can do with shader-simulated fluids.

You're bored again! I know! Here's it at 16 to a side.

Weird behavior here! The heightmap doesn't conserve "volume" I guess. It kinda shudders upwards. Does it always go up? The way I create the ripple is by setting the center cell's rate of height change to 2. Effectively I'm firing a pellet upwards from the center of the fluid. What if I set the rate of height change to -2--fire the pellet downwards?

Hah! The whole field goes down instead! There's an alternate way to achieve the ripple effect, though--I set the height of the center cell directly, rather than its rate of change. I'm lifting a column of water and letting it fall back down.

Huh. No significant change. Same when I push the height down rather than up. I guess the change in height dissipates more quickly than the change in velocity? The height change has to have some effect, but I guess it's small enough that there's no perceivable vertical change by the heightmap. By the way, I'm sure this change in median height happens to the higher resolutions as well, but because the amount of cells is higher the impact of a single cell's difference dissipates even quicker. I bet there's a mathematical reason for the difference in the effects of height change vs velocity change but I don't know how to find it.