Perlin noise documentation

[processing-bugs]

Issue by solsword
Friday May 30, 2014 at 05:44 GMT
Originally opened as processing/processing-web-archive#423

---

The documentation for the noise() function claims that it is a Perlin noise implementation. Actually, the noise function it implements is value noise [1], which is not nearly as good for most applications as real Perlin noise (see a comparison at [2]). The documentation should be updated to reflect this, especially given the frequent confusion of value noise and Perlin noise and the fact that Processing is probably for many their first introduction to the concept of continuous noise functions.

[1] http://en.wikipedia.org/wiki/Value_noise
[2] http://imgur.com/guiiWRU

[processing-bugs]

Comment by AmnonOwed
Friday May 30, 2014 at 07:06 GMT

---

Yeah, it has been like that for many, many years. Also see this discussion in the old forum. Processing's noise function is a java port of the noise implementation by the german demo group farbrausch as used in their 64k demo Art (2001). And indeed it's not really Perlin noise even though the documentation and all the introductory books claim it is. I assume this claim is actually made to keep things simple for beginners at the cost of some accuracy in the description. However it may lead to confusion later on, as it did for me in the linked thread, when I used real Perlin noise in a GLSL shader and suddenly got different results.

I see you have already filed processing/processing#2549 as well which got fried. Perhaps updating the documentation is the quickest and easiest solution here. However, I think an alternative, possibly better, solution to this would be to add a noiseMode() method with two parameters VALUE (default) and PERLIN (or optionally even include a SIMPLEX mode). That way the results of the noise() method could be set from an external noiseMode() method, similar to the rectMode(), textureMode() methods already used in Processing. That way while in noiseMode(PERLIN) the noise() method would actually provide Perlin noise for those who need it. But at the same time all existing sketches would remain consistent (given the default noiseMode(VALUE) setting) without requiring any code changes, as noise() is used in a lot of sketches. And then these changes could be reflected in the documentation. The only downside of the latter solution would be that someone would have to write a Perlin noise implementation, add a new noiseMode() method, add noise-related constants and finally add and update descriptions in the reference. In short, it's much more work while lacking some urgency, since this issue is traditionally only raised by "noise purists". Also, I don't know how Processing's dev team feels about such a proposed solution.

Anyway, that's my $0.02! :-)

[processing-bugs]

Comment by clankill3r
Tuesday Jun 03, 2014 at 07:48 GMT

---

I'm up for AmnonOwed's solution using the noiseMode().

[processing-bugs]

Comment by REAS
Tuesday Jun 03, 2014 at 17:52 GMT

---

I'll discuss noiseMode() with the group. For now, and related to the Issue title, I'll fix the documentation first.

[processing-bugs]

Comment by clankill3r
Sunday Jun 08, 2014 at 23:51 GMT

---

If you would implement a noiseMode, then it would be nice if changing the mode won't have to much impact on the scale. So not like the image where one is much bigger then the other.
If they would have a significant difference in scale then it would be much harder to change between noiseModes.

[processing-bugs]

Comment by REAS
Monday Jun 09, 2014 at 03:54 GMT

---

After discussion, we decided to not implement noiseMode() and to keep noise() as it is. More noise features is a good candidate for a Library or examples to share with the community. I will adjust the description in the reference in the next round of editing.

[REAS]

OK, group. I tagged the following to the end of the noise() reference:

There have been debates over the accuracy of the implementation of noise in Processing. For clarification, it's an implementation of "classic Perlin noise" from 1983, and not the newer "simplex noise" method from 2001.

I am closing Issue #51 out, but I can make further edits to it if there are reasonable corrections or a persuasive dissenting opinion.