Simplex noise vs Perlin noise

Question

I would like to know why Perlin noise is still so popular today after Simplex came out. Simplex noise was made by Ken Perlin himself and it was suppose to take over his old algorithm which was slow for higher dimensions and with better quality (no visible artifacts).

Simplex noise came out in 2001 and over those 10 years I've only seen people talk of Perlin noise when it comes to generating heightmaps for terrains, creating procedural textures, et cetera.

Could anyone help me out, is there some downside of Simplex noise? I heard rumors that Perlin noise is faster when it comes to 1D and 2D noise, but I don't know if it's true or not.

Thanks!

Answer 1

Some preference for the classic Perlin noise may come from being able to use known values resulting in known visual characteristics, as opposed to investing the time required to find the input parameters needed to get an equivalent output using simplex noise.

[simplex noise] has a slightly different visual character to it, so it’s not always a direct plug-in replacement for classic noise. Applications that depend on the detailed characteristics of classic noise, like the precise feature size, the exact range of values or higher order statistics, might need some modification to look good when using simplex noise instead.
Stefan Gustavson's Simplex noise demystified

Answer 2

Just some anecdotal experience, the reason I used classic Perlin noise was because Ken Perlin had a C implementation of classic Perlin noise, while providing a Java implementation of improved Perlin noise. Silly as it may sound, classic Perlin noise was easier to copy and paste into my program, so that is why I used it. I always intended to get around to porting that Java implementation, but classic Perlin appeared to work well enough, so I never bothered to add it.

Stefan Gustavson has some very good C implementations of Simplex Noise, here

Answer 3

Ken Perlin patented his simplex noise algorithm. His classic algorithm is not patented to my knowledge.

Answer 4

I haven't worked with simplex noise yet, but I can think about a few reasons:

• Perhaps because we're used to squares and 90 deg angles? Squares, Cubes,... are much more natural to us than triangles, tetraeders or hyper-tetraeders.
• Each layer in perlin noise is just a simple bitmap.
• The output of perlin noise are easily tileable squares. And textures are often tiles squares.
• You usually use low dimensional noise. In my experience 2D and 3D are most common.
• Simplex noise is simply harder to understand an implement
• Probably the samplers in a graphic card can do the interpolation for orthogonal bitmaps as used in perlin noise, but not the interpolation on 60 deg angles bitmaps used in simplex noise. (this point might be wrong, I haven't worked with graphics cards for a few years)

Answer 5

I wouldn't be at all surprised if it was simply because of the name. You have to choose between Perlin noise and Simplex noise. The latter is newer and has some advantages. But, you know, it sounds like the 'simple' version of the two. I'll go with the complexer one; noise is supposed to be complex, isn't it?

People tend to be rather irrational.

Answer 6

I would answer the question bluntly I would say it is because Perlin noise is super simple to get your head around. Simplex noise on the other hand is very much a more complex and hairer beast. Getting a Perlin implementation up and running is much easier than simplex and thus gets more usage. It does not help simplex's case that both are very similiar in the visuals (especially after you manipulate the noise a bit).

Kenneth Perlin himself designed the simplex algorithm for an hardware based implementation and thus made design decisions that make this easier. One example of this can be seen in this quoute, from the patent.

Need for table memory: The original Noise algorithm relied on a number of table lookups, which are quite reasonable in a software implementation, but which in a hardware implementation are expensive and constitute a cost bottleneck, particularly when multiple instances of the Noise function are required in parallel. Ideally, a Noise implementation should not rely on the presence of tables of significant size.