Hi,
I was looking at the code you're using to implement the processing "noise" function - its a
pretty poor implementation (slow, lots of lattice artefacts, statistically incorrect). I'd
recommend using Ken Perlin's "fast noise" - http://mrl.nyu.edu/~perlin/noise/ its a much
better implementation and doesn't even require a random number generator.
I'll put up a web page at
http://www.csse.monash.edu.au/~jonmc/resources/processing/noise.html to illustrate the
problem.
Regards,

Jon.

toxi, your thoughts?

I don't claim any ownership of that implementation and as said in the
comments this was taken from a demoscene production where they made a
trade-off for speed reasons. Also at that time I wasn't aware of Ken
Perlin's improved version. The only other perlin noise code I knew of was
magnitudes slower than the current one.

But by all means go ahead and replace the code with Jon's proposed one. The
only issue I can see is that we'd need to take care of the noiseDetail
functionality, since this doesn't seem to be currently there (in the new
code). In fact you'd hardly ever use perlin noise with just a single octave
(as in the demo). The Processing default is 4 octaves and there the
artefact problem is not obvious...

Speaking of improved noise you might also want to have a look at the Java
implementation of Perlin's SimplexNoise, which is appararently even
"better" and has built in accessors up to 4D:

http://staffwww.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf

If you were to replace it and wanted to maintain the current interface calls it would be easy
to implement the "noiseDetail" and "noiseSeed" functions (although the idea of a seed for a
noise function doesn't make sense - its supposed to return the same value for any given
coordinate). Extending to 4D (or higher) versions is pretty trivial. Also, another minor
technical point - having a "noiseDetail" function is really a turbulence function (summed
octaves of noise), which would normally be considered different than a noise function, since
you can sum other things apart from noise. There are *lots* of uses for single octave noise -
having a default of 4 seems to be there to compensate for the poor quality of the single
octave noise :-)
Regards,

Jon.

i think we're gonna table this for later.. the benefit of changing things
isn't outweighed by breaking all the existing apps that use the noise()
function in its current state.

we'll look toward changing in when we next make a clean break in the api
(e.g. 2.0) and switch to a different noise algorithm.