Uniformly Distributed Perlin Noise

[jeremym]

I want to be careful about talking about the processing implementation as it was brought to my attention that it isn’t really a direct port of the original algorithm but a little bit of testing seems to show the principle works, at least to a point. (Stress on little bit… “very little bit” might be better.)

With that caveat out of the way… Let’s be specific about what using a scaling factor is actually doing. “Scaling” and “zooming” are a bit hand-wavy. It is really just modifying the argument to the noise function.

For this example, we’ll keep it to 1D to keep it simple. And for the same reason let’s pretend that the periodicity is simply 1 instead of a higher number. So, for example, noise(0.2) and noise(1.2) return the same value.

So let’s call noise in a loop…

for (int x=0; x<10; x++).{ 
  noise(x * scl)
}

If scl is 1, it’s obvious we’ll get the same value each time. If scl is .5, we’ll bounce between only two different values… but if scl is .6 we’ll get 5 different values… .6, 1.2, 1.8, 2.4, 3.0 and the next value is 3.6, a repetition. (since our period is 1, only the fractional part matters.) If we choose .25, we get 4 different values… if we choose 0.26, we should get 50 values, I think.

So, choosing a scaling factor that doesn’t divide the period evenly does give you “more” noise.

[jeremym]

Some thoughts I think I should add… there are two other things to consider when using noise for visual effects. One is that, by design, values in noise space change gradually, so if you use arguments that are near each other, you get return values that are near each other. And the other is that generally those return values are mapped to integers in some limited range (often just 0-255) which effectively loses some of the variation the function is returning. Bottom line is that a lot of the repetition you get from the function may not be exact, but may be close enough that, for practical purposes, it might as well be.

This is an argument against my assertion that using scaling factors that don’t divide evenly into the period will result in less repetition. While technically true, it may not make a noticeable difference in practice much if not most of the time.

UPDATE: Here’s a little code to illustrate the point.

float nzs1 = .5; 
float nzs2 = .5107932; 

void setup() { 
  size(512,512, P2D); 
  background(0);
  noiseSeed(0);
  beginShape();
  stroke(255); noFill();
  for (int x=0; x<width/4; x++) {
    int y = int(map(noise(0,0,x*nzs1), 0, 1, 0, 255));
    vertex(4*x,y); 
  }
  endShape();
  beginShape();
  stroke(255); noFill();
  for (int x=0; x<width/4; x++) {
    int y = int(map(noise(0,0,x*nzs2), 0, 1, 256, 511)); 
    vertex(4*x,y);
  }
  endShape();
  stroke(255);
  strokeWeight(1);
  line(0,420,width,420);
  line(0,205,width,205);
  line(0,184,width,184);
  line(0,31,width,31);
  stroke(255,0,0);
  ellipse(105,420,30,30); 
  ellipse(480,420,30,30);
  ellipse(110,375,30,30); 
  ellipse(485,375,30,30);
  noLoop();
  saveFrame("noise##.png");
}

[Divitiacus]

Your argument would be true, if the noise for the in between numbers is created from the unique numbers. If there is a limited array of numbers used (as there is for Perlin noise), the question is, how many unique noise values are calculated between 0.2 and 1.2.

The other question is then what is done with the numbers between the unique noise values. Usually a type of interpolation is done. These interpolations doesn’t create new information. If I create a unique noise value of 0.4 and another of 0.8 interpolation just puts all points in between on a line or curve. Creating more points just means there are more points on the same line, but there is not more detail created.

Therefore, making more points with the scaling factor just spreads the unique noise values more apart, if that makes sense. It doesn’t help to create better noise, except I cycle through the number array in a different way. But also that is limited by the total number of numbers I can cycle through.

[Divitiacus]

I really like this noise function.
Never thought about using the frameCount to create continuous movement but it works really well. The movement done this way is more organic than with the standard noise. In the standard noise there is always some visible transition point. Unfortunately, no videos can be attached to show.

Just for fun some picture: