rieldevblog

[rieldevblog]

It’s raining

[rieldevblog]

Hoo boy, this had some bullshit in it, huh?

A CORRECTION

For the functions M(x) = (a+b+c+d)/4 - x and N(x) = a+b+c+d - 4*x, M almost never equals N except where x = (a+b+c+d)/4. So that thing I said about M being equal to N when x is non-zero is some bullshit. I don’t know how I convinced myself of it. Here, you can even calculate the difference:

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

So to find when they are equal, you’d say

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

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

    => (a+b+c+d)/4 = x when M(x) = N(x)

So yeah that was some bullshit that I said.

I also forgot some images. Here they are in their intended context:

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. 

Okay! Corrections done. Now to work on solid coupling.

HAH! Took me a hot minute, but I got the simulator to work with meshes AND I generalized the system so it should work with models, shaders, whatever! Plus I made some parameters customizable through the Unity editor. Technical details and more videos under the cut!

Keep reading

[rieldevblog]

HAH! Took me a hot minute, but I got the simulator to work with meshes AND I generalized the system so it should work with models, shaders, whatever! Plus I made some parameters customizable through the Unity editor. Technical details and more videos under the cut!

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!

*See my last post. Essentially, if the surrounding cells are, on average, higher than the center cell, the center will move up, and if they’re lower, the center cell will move down.

[rieldevblog]

Very simple heightmap fluid simulation! It’s a super simple algorithm and the resolution is pretty low but you can still see ripples, reflections, and interference patterns (watch the corners). More videos and technical details under the cut.

Keep reading

[rieldevblog]

Very simple heightmap fluid simulation! It’s a super simple algorithm and the resolution is pretty low but you can still see ripples, reflections, and interference patterns (watch the corners). More videos and technical details under the cut.

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.

Anyway! Hope the videos were interesting, if nothing else. Feel free to ask me any questions. I friggin' love the way these look: the crazy-lookin start, the highly ordered first ripple, the cross section of the wave on the edge, and the way the pattern devolves into chaotic vibrations. Hopefully you'll see even more soon.

[rieldevblog]

Welcome

Hi, I’m an okay programmer, you can call me Riel (pronounced “real”). I’m welcoming you as much as I’m welcoming myself. I’ll occasionally post some interesting simulation-y software stuff here.

I’ve spent a lot of time and effort making software things in the past but I’ve never shown anyone. Mostly because they weren’t very visual projects--I was, like, implementing data structures and making engines for things but never writing the visual or UI side. I didn’t think anyone would be interested in a bunch of code and a step-by-step console printout of Conway’s Game of Life.

But recently I had an idea. I won’t tell you exactly what it is because it may never materialize. Let it suffice to say that it would require a lot of simulation and working in 3D environments and other skills that I don’t have yet. But I want to explore the idea. So I downloaded Unity and started doing some research and hey, now I have some cool-looking visuals. They will be posted here, along with brief explanations. I hope it’s compelling.