My last post on Perlin noise wound up on hitting Hacker News, which generated an enormous amount of views, and a fair number of comments – here, on Twitter, and on HN itself. Of course, there was the usual eye-rolling, condescending, “why doesn’t he just do ….? that would be the obvious approach” kind of comments there, but a fair amount of actual helpful ideas, explanations, and links. One thing that came up over and over was the idea of using curl noise. So, when I got a chance, I went ahead and used curl noise.
Funny thing is, I thought I knew what curl noise was and would have said that I’ve used it before. But when I read through some of the links provided, it turns out my concept was way off. What it really is is finding out the slope on the current path of the particle and using that to determine its new velocity. But you need to get the delta of the Perlin noise on both the x and y axes, which in most implementations requires four separate calls to the noise function. Still, it runs pretty well with 500 particles above. And looks pretty nice.
By default, you’ll wind up with some vortexes, as the particles travel the same general paths. In the above example, I used 3D Perlin noise and allowed the z parameter to change over time (you can control how fast it changes with the “Noise Speed” slider). This changes where the vortexes are over time and gives a nice effect. Still quite a different feel to what I was doing the other day.
Which one will I use? Depends on the use case I guess. The “multiply-and-scale-down” strategy I came up with in the last post is probably the best bang for the buck in my opinion. Very simple, performant, and looks good. Curl noise is a bit more complex and calculation intense, but looks very good as well. Curl noise has the benefit of being incompressible, meaning that the particles will generally stay separate. Compare today’s example with the ones from the other day. You’ll see that the particles tend to clump together in the “valleys” of the noise landscape in the earlier examples. This could be good or bad, again depending on the use case.
They are both good tools to have in the kit.
Here are some of the links I was shared, along with some I dug up myself.