Why does simplex noise seem to have *more* artifacts than classic Perlin noise?

Question

I read Stefan Gustavson's excellent paper on simplex noise, in which I was promised that:

Simplex noise has no noticeable directional artifacts

in contrast with "classic" Perlin noise. I excitedly implemented it to find out that the opposite appeared to be true. I do see artifacts in classic noise, but I see at least as many artifacts in simplex noise, aligned at 45 degrees to the main axes. They're especially noticeable when you map the noise to a step function.

To ensure it wasn't a problem with my implementation, I used someone else's JavaScript implementation. Compare some images:

• Classic noise vs simplex noise
• Classic noise step vs simplex noise step

And here's a gallery with all of them. In that last image, look for borders that are aligned at 45 degrees from horizontal/vertical. They're all over the place. I can highlight some of them if need be, but they seem really obvious to me. (And again, I see them in the classic noise image as well.)

EDIT: To be more quantitative, I sampled 1 million random points, and for each point I numerically computed the gradient of both classic and simplex noise, and took a histogram of the direction of the gradient projected onto the x-y plane. If there were no directional artifacts, the graph would be flat. But you can see that both classic and simplex noise spike every 45 degrees.

Is this a problem with the simplex noise algorithm? Is it something that can be fixed? Or am I the only one who sees this as a problem?

Tingaling

I completely agree that the step version looks dodgy, but the unstepped versions look fine. How are you stepping the values? – Fraternity

Any pixel with a color value above 128 gets mapped to one color, values below 128 get mapped to the other color. It's basically a contour map, like you'd get with land vs water if you used this to generate terrain. (Terrain generally uses fractal noise, which eliminates directional artifacts.) – Tingaling

Answer 1

I just read the paper, and I think I have an idea what might be causing the artifacts. The gradients for each vertex of the grid are pseudorandomly chosen from a rather small lookup table. As Gustavson states on page 3:

"A good choice for 2D and higher is to pick gradients of unit length but different directions. For 2D, 8 or 16 gradients distributed around the unit circle is a good choice."

This was the method used in classical Perlin noise, which is not what Perlin proposed for Simplex noise in his 2001 paper, page 14:

"Rather than using a table lookup scheme to compute the index of a pseudo-random gradient at each surrounding vertex, the new method uses a bit-manipulation scheme that uses only a very small number of hardware gates."

However, Gustavson states on page 7:

"I will use a hybrid approach for clarity, using the gradient hash method from classic noise but the simplex grid and straight summation of noise contributions of simplex noise. That is actually a faster method in software."

His 2D implementation actually uses the 12 gradients from the 3D gradient table, discarding the z coordinate. In that scheme, the edge coordinates are used twice each, but the corners are used only once, which would seem to introduce a bias at 90-degree intervals. But that's not relevant in your case, because the implementation you're using only has 8 gradients, quite suggestive of a bias at 45-degree intervals. The likelihood of visible patterns emerging from such minimal variance seems pretty high. But it should be easy to adapt that algorithm for 16 gradients, using a mod 16 permutation table, which should help reduce the directional artifacts significantly.

Ultimately, though, I think there will always be some visible patterns in a single octave of any gradient noise function, simply because they're band-limited by design, as the narrow range of frequencies will tend to align perturbations to the grid. Being a triangular grid, Simplex noise will probably exhibit some bias at 60-degree intervals even if the gradients were truly random. Well, that's just conjecture, but the point is that these noise functions are really designed to be combined in different frequencies, which tends to break up any patterns you might see in a single octave.

EDIT:

Another point I just realized, the corner gradients such as (1,1) are not of unit length, they are sqrt(2). The first quote makes it clear that the gradients should lie on the unit circle. This may be another source of bias. Interestingly, Gustavson uses these non-unit gradients too.

Atop

Worth noting that the 'hybrid approach' makes it not simplex noise but rather a mix of Perlin noise and simplex. – Finecut

Answer 2

Value noise version of perlin noise produces straight lines also, and gradient noise version of perlin produces slightly rounder stuff, so maybe you have a value noise implementation of simplex there rather than a gradient version.

Otherwise the interpolation gradient in your code is wrong, because it is producing angle transitions in between quadrants. it seems online to say that simplex noise is not only faster but that the gradients are more rounded.

I interpret that to mean that the angles of the interpolation curves are rounder. Perhaps someone has mis stated Ken Perlins statement, he just said that the gradient contained less jitter(sorry for use of the wrong description), because the code doesn't actually produce a perfect mathematical curve like a sinus, if you multiply many Perlin together I found jitter/curve irregularities strong enough to measure, which is not the case with sine waves and maths functions. so you could research online other people's comments of simplex noise gradient.

I think there is a gradient look up table, which in your case it seems to be going up to 45' rather often, otherwise the grading curve that you are using in between 2 points is too far from the idealised sinusoidal curve that would produce round shapes and no straight lines at all, but that's computation less easy, especially on CPU. On GPU I think it stands to reason that sinus gradient with the faster than the polynomial gradient curve used.

did you also check what the turbulent and multi-fractal etc versions of your simplex make? In either case they are each about 5 lines expressing how the noise functions run and returning very different results every time.

improved Perlin noise for GPU from scrawkblog

Elma

I checked the code (which is not mine) and it looks like a direct translation of Gustavson's. Here's the gradient part. If you have different code that you believe to be correct, I can run it and compare. I've also generated value noise and yes, it's much worse than gradient noise for directional artifacts. I've also compared turbulent and fractal noise. While this helps eliminate artifacts, it also does so for classic noise (and even value noise!). So in no case do I see simplex noise with fewer artifacts than classic. – Tingaling

you have made a very interesting find, perhaps Gustavson was too zealous in his introduction simplex, perhaps all the code deriving from his Java is missing interpolation, I don't know. I would have thought that it was not possible for so many points to be on 0 and 1 values so as to create all 45' angles. I checked and many implementations of simplex give the same result as you, and they are mostly derived from his Java code. – Elma

I checked by quantising the colours in gimp and found always the same problem angles in this way: google.fr/… – Elma

as it is a very pertinent question and it makes the leading resource on simplex misleading, you should write to k perlin and Gustavson for their take on things. I am currently using the advanced Perlin implementation for GPU from scrawkblog, the resulting curves seems very random. – Elma

perhaps solution-notice that on the above link, on the worst Simplex noise, he states it is 64 resolution, and next to there is really nice looking Simplex noise, which he states is being 128 and 512 resolution. I don't know if that's the number of values in the permutation table? what do you reckon? – Elma