<p>Yep, you've got that right. In Perlin's reference implementation of "improved noise", the noise will be periodic, repeating after 256 units along each axis. It's usually not very noticeable even if you have a large extent of noise visible, since there's no large-scale features for the eye to track.</p>

<p>But there's no particular reason it needs to tile after 256 units; that's pretty much just an arbitrary choice made by Perlin. He uses a permutation table as a hash function to map grid coordinates to gradient vectors, and the hard-coded table is of size 256, so has to be tiled after that.</p>

<p>However, any other hash function you like could be used as well. It just has to pseudorandomly map the integer parts of the x, y, z coordinates to a gradient vector.</p>

CC BY-SA 3.0
2017-11-10T03:11:42.277Z
2017-11-10T03:11:42.277Z
Nathan Reed
<p>I am following this tutorial: <a href="http://flafla2.github.io/2014/08/09/perlinnoise.html" rel="nofollow noreferrer">Understanding Perlin Noise | Blog</a></p>

<p>To understand Perlin Noise. In particular, right now I am focusing on the following code section:</p>

<pre><code>int xi = (int)x &amp; 255; // Calculate the "unit cube" that the point asked will be located in
int yi = (int)y &amp; 255; // The left bound is ( |_x_|,|_y_|,|_z_| ) and the right bound is that
int zi = (int)z &amp; 255; // plus 1.  Next we calculate the location (from 0.0 to 1.0) in that cube.
double xf = x-(int)x;
double yf = y-(int)y;
double zf = z-(int)z;
</code></pre>

<p>If I am correct, the first 3 lines of code are calculating a set of 3 coordinates (xi,yi,zi) that range from 0 to 255 inclusive, as integers. This is, in other words, a 255x255x255 3D grid of unit cubes.</p>

<p>The next 3 lines are calculating the relative 0-1 coordinates inside of the cube in the grid the point (x,y,z) is mapped to.</p>

<p>My question is:</p>

<p>Is there any reason for this number to be 255? Or is this simply a number that was chosen because it made the algorithm faster (smaller grid, less numbers, faster hash lookup, caching...) and could easily be extended to any other integer (theoretically).</p>

<p>In either case, won't this generate a repetitive pattern?</p>

<p>What I mean by the second question is: If I have a set of (x,y,z) values that extend to "infinity" at regular intervals (let's say they all change at intervals of 1), won't I start seeing a clearly predictable/repetitive pattern emerge after around 255 steps in a given direction? </p>

<p>Finally, if a repetitive pattern emerges, how can you create more variation while keeping pseudo randomness?</p>

<algorithm><noise><procedural-generation>
Help understanding Perlin Noise
Makogan
# Help understanding Perlin Noise

(Asked by: username_0 on 2017-11-09)

I am following this tutorial: [Understanding Perlin Noise | Blog](http://flafla2.github.io/2014/08/09/perlinnoise.html)

To understand Perlin Noise. In particular, right now I am focusing on the following code section:

```
int xi = (int)x & 255; // Calculate the "unit cube" that the point asked will be located in
int yi = (int)y & 255; // The left bound is ( |_x_|,|_y_|,|_z_| ) and the right bound is that
int zi = (int)z & 255; // plus 1.  Next we calculate the location (from 0.0 to 1.0) in that cube.
double xf = x-(int)x;
double yf = y-(int)y;
double zf = z-(int)z;

```

If I am correct, the first 3 lines of code are calculating a set of 3 coordinates (xi,yi,zi) that range from 0 to 255 inclusive, as integers. This is, in other words, a 255x255x255 3D grid of unit cubes.

The next 3 lines are calculating the relative 0-1 coordinates inside of the cube in the grid the point (x,y,z) is mapped to.

My question is:

Is there any reason for this number to be 255? Or is this simply a number that was chosen because it made the algorithm faster (smaller grid, less numbers, faster hash lookup, caching...) and could easily be extended to any other integer (theoretically).

In either case, won't this generate a repetitive pattern?

What I mean by the second question is: If I have a set of (x,y,z) values that extend to "infinity" at regular intervals (let's say they all change at intervals of 1), won't I start seeing a clearly predictable/repetitive pattern emerge after around 255 steps in a given direction?

Finally, if a repetitive pattern emerges, how can you create more variation while keeping pseudo randomness?

**Tags:** algorithm, noise, procedural-generation


---

## 1 answers

### Answer by username_1 on 2017-11-10. Score: 3 | Accepted answer

Yep, you've got that right. In Perlin's reference implementation of "improved noise", the noise will be periodic, repeating after 256 units along each axis. It's usually not very noticeable even if you have a large extent of noise visible, since there's no large-scale features for the eye to track.

But there's no particular reason it needs to tile after 256 units; that's pretty much just an arbitrary choice made by Perlin. He uses a permutation table as a hash function to map grid coordinates to gradient vectors, and the hard-coded table is of size 256, so has to be tiled after that.

However, any other hash function you like could be used as well. It just has to pseudorandomly map the integer parts of the x, y, z coordinates to a gradient vector.


---

