Noise() periodicity different in each dimension?

[jeremym]

Through a bit of trial and error I’ve discovered that the period of perlin noise produced by the noise() function differs in each dimension. Specifically, the period in the x dimension is 4096 ,the period in the y dimension is 256, and the period in the z dimension is 16.

I’m wondering why these are different. Can anyone enlighten me?

I haven’t looked at other implementations of the 1983 algorithm, so perhaps this is just the way it works… It’s just a little counterintuitive to me that it isn’t a cube of noise with equal periods in each dimension.

The following sketch is what I used to determine the periods… I just manually changed nxs, nys, and nzs until I got all squares to be (and stay for z) the same color. The fact that the periods were powers of two were already evident to me from other experiments.

float nxs = 4096;
float nys = 256;
float nzs = 16;
float z=0;

int cell_size= 40;

void setup() {
  size(640, 640, P2D);
  colorMode(HSB);
}
 

void draw() { 
  for (int x=0;x<width/cell_size;x++) { 
    for (int y=0;y<height/cell_size;y++) {
      fill(color(map(noise(x*nxs,y*nys,z), 0, 1, 0, 255),255,128));
      rect(x*cell_size, y*cell_size, cell_size, cell_size);
    }
  }
  z+=nzs;
}

[javagar]

The same effect occurs with the p5.js implementation. Try this conversion of your code:

let nxs = 4096;
let nys = 256;
let nzs = 16;
let z = 0;

let cell_size = 40;

function setup() {
  createCanvas(640, 640, P2D);
  colorMode(HSB);
}

function draw() {
  for (let x = 0; x < width / cell_size; x++) {
    for (let y = 0; y < height / cell_size; y++) {
      fill(color(map(noise(x * nxs, y * nys, z), 0, 1, 0, 255), 255, 128));
      rect(x * cell_size, y * cell_size, cell_size, cell_size);
    }
  }
  z += nzs;
}

[jeremym]

Seems true enough, but is this surprising? I thought p5js was purposefully implemented to be similar to (java) Processing, so I’d kind of expect its implementation of the noise() function to be equivalent.

[javagar]

@jeremym

… but is this surprising?

No, I had guessed that it would be similar, but it was worth verifying that. It does seems an unfortunate artifact that there is periodicity in the algorithm or its implementation at all, and additionally unfortunate that it differs among the three dimensions.

[jeremym]

I don’t find the periodicity itself to be unfortunate. You can use it for specific effects. I don’t like that it differs in the 3 dimensions, but now that I know what the periods are, that’s not a big deal either.

If you don’t want repetition at all, the key, I think, is to use a scalar that doesn’t divide evenly into the period. So instead of 0.02 you might choose 0.0237 or something.

[mnse]

Hi,

Maybe you also find this interesting…

Understanding 2D Perlin noise

Hello, I know this topic was discussed before here, but I would like to understand, how Perlin Noise in 2D is implemented in Processing, so that I can use it consciously. In other topics it was mentioned before, that Perlin Noise is repeating after certain numbers: On this side it was mentioned Perlin noise repeats every 256 units in each coordinate direction: stackoverflow.x/questions/9577259/perlin-noise-function-returning-same-results-for-different-inputs/9577407#9577407 x= com Howeve…

Cheers
— mnse

[javagar]

@jeremym

If you don’t want repetition at all, the key, I think, is to use a scalar that doesn’t divide evenly into the period

Yeah, that’s fine for practical purposes. But am I mistaken in thinking that the ideal, though it be mathematically unachievable, is for noise to provide an essentially smoothed three dimensional random universe that we can sample?

[jeremym]

@mnse

Maybe you also find this interesting…

Thanks. The stackoverflow thread it references points to Ken Perlin’s improved (2002) noise function which, in his own java implementation anyway, appears to have a periodicity of 256 in each dimension. I know Processing uses his earlier 1983 algorithm though, and I can’t find code for that on his site.

[javagar]

@javagar

… though mathematically unachievable, is for noise to provide an essentially smoothed three dimensional random universe that we can sample?

Ah, I see from @mnse’s reference that it is expected to be amenable to tiling, so evidently periodicity is desired.

[jeremym]

@javagar

But am I mistaken in thinking that the ideal, though it be mathematically unachievable, is for noise to provide an essentially smoothed three dimensional random universe that we can sample?

Well, I don’t know… depends on intentions, I guess. There are always going to be limits though. Even if you could construct such an algorithm in theory, you’d be limited by the floating point values your machine can represent. I mean, imagine perlin noise periodicity was 1 in every direction. There are still an infinite number of floating point numbers between 0 and 1 so I guess you could theoretically get an infinite amount of noise even in that case if you could represent numbers small enough … (and I suppose you’d have to have enough octaves to get the same quality.)

I should be clear that I’m not really making any claims about existing noise algorithms (which I’ve only recently become interested in) but more just braindumping some theoretical musings.

[Divitiacus]

If you look to the last post in the thread @mnse shared, I did describe that the processing implementation just uses 4096 values and interpolates between them with cosine. You can try to cycle through 16 values (in 3D) a little bit longer by dividing by uneven numbers but in the end you recycle the same values over and over again.

It is neither Perlin Noise nor any good noise. Thanks to @micycle a good implementation exists now. That is much appreciated.

[jeremym]

Thanks. I’m using 3.5.4, but I found that code on github as well. I also found Ken Perlin’s original 1983 code at:

https://web.archive.org/web/20160307063404/http://mrl.nyu.edu/~perlin/doc/oscar.html#noise

I’m playing with that right now. I’ll take a closer look at the processing implementation later.