**Contents**

**News (August, 31)**: We are working on Scratchapixel 3.0 at the moment (current version of 2). The idea is to make the project open source by storing the content of the website on GitHub as Markdown files. In practice, that means you and the rest of the community will be able to edit the content of the pages if you want to contribute (typos and bug fixes, rewording sentences). You will also be able to contribute by translating pages to different languages if you want to. Then when we publish the site we will translate the Markdown files to HTML. That means new design as well.

That's what we are busy with right now and why there won't be a lot of updates in the weeks to come. More news about SaP 3.0 soon.

We are looking for native Engxish (yes we know there's a typo here) speakers that will be willing to readproof a few lessons. If you are interested please get in touch on Discord, in the #scratchapixel3-0 channel. Also looking for at least one experienced full dev stack dev that would be willing to give us a hand with the next design.

Feel free to send us your requests, suggestions, etc. (on Discord) to help us improve the website.

And you can also donate). Donations go directly back into the development of the project. The more donation we get the more content you will get and the quicker we will be able to deliver it to you.

A few years later (in fact in 2002, so 17 years after Perlin published his first paper on noise), Perlin proposed a new improved version of his noise function. The original noise function has two problems.

## The smoothstep function is not ideal and here is why...

First, remember that the interpolant we used to interpolate the result of the dot product between the gradients and the vectors pointing toward the point within the cell, is the smoothstep function. This function has the form \(3t^2 - 2t^3\). Remember as well that we used the derivative of this function (\(6t - 6t^2\)) to compute the Noise function partial derivatives. As explained in the previous chapter, these derivatives are useful to compute the "true" normal (true as in mathematically correct) of vertices displaced by a noise function. Now the problem with this is that the derivative of the smoothstep function derivative (what we call in mathematics the second order derivative or \(f''(x)\)) is not continuous when \(t=0\) or \(t=1\). The second order derivative of the smoothstep function is \(6 - 12t\). So when \(t=0\) \(f''(x)=6\) and when \(t=1\), \(f''(x)=-6\). This is a problem because if the derivative of the function used to compute the normal of the displaced mesh is not continuous then it will introduce a discontinuity in these normals wherever \(t=0\) and \(t=1\). That happens when the vertices of the displaced mesh are aligned with the edges of the noise grid cells (i.e. when the vertices coordinates have integer values). These visual artefacts are clearly visible in the image below (left).

It is important to understand that while the analytical solution to compute the noise function derivative is correct mathematically, this doesn't mean that the result is necessarily visually what we look for. This is nothing else than a mathematical construct and this construct may have properties we don't like. So while the results are mathematically correct, they create visual artefacts we would rather prefer to avoid.

Furthermore most documents mentioning the problem of this function don't really explain why we have this problem and provide a way of visualising it. To better understand why the problem is there in the first place, you need to remember a detail about functions and function derivatives. In physics, a common function is the function that allows you to compute the **position** of a moving object as a function of a time. Let's call this function \(p(t)\). If you recall your lessons on physics, you can compute the **speed** of this object as the derivative of this function with respect to time, in other words \(p'(t)=p(t)/\partial t\). And finally you can compute the object **acceleration** as the derivative of the speed function with respect to time again or \(p''(t)=p'(t)/\partial t\). So in essence you can see a function \(f(x)\) and its derivatives \(f'(x)\) and \(f''(x)\) as respectively the position, the speed and the acceleration of an object. In our example the smoothstep function is by analogy, the position, the first order derivative of the smoothstep function that we used to compute the tangent is the speed and finally the second order derivative of the smoothstep function is the acceleration. Of course these are just analogies. But the point is, if the acceleration has discontinuities, then we can expect the speed to change abruptly from time to time. In our particular case, this means that if the smoothstep function second order derivative has discontinuities, then we can expect the tangent to vary abruptly from time to time. And that's precisely what causes the visual artefacts at the cell boundaries. The normals in these regions change abruptly.

The image below shows a slice of the noise function and its analytically computed normals. It is pretty clear that the orientation of the normals and the direction of these normals is not the same on each side of the cell boundary.

Hopefully there is a solution. Well, if the only problem is that the second order derivative of the smoothstep function is discontinuous then all we need to do to fix the problem, is to choose a function for the interpolant that has a second order derivative that is, obviously, continuous. There are quite a few of them that have a similar shape to the smoothstep function but Perlin choose this quintic function (figure 1):

$$6t^5-15t^4+10t^3.$$Its first order derivative is:

$$30t^4-60t^3+30t^2.$$And its second order derivative is:

$$120t^3-180t^2+60t.$$As you can see this function is continuous (when t=0 and t=1 the function is equal to 0).

## Choosing random gradients is not ideal and here is why...

The next problem is that because the gradients are chosen randomly, sometimes the gradient directions are aligned along the same axis or along the diagonal of the cell as showed in figure 2 [missing]. The noise function tends to take on very high values in these regions (close to 1) causing in parts the "splotchy appearance" of the original Noise implementation.

Hopefully this problem can be solved easily by replacing the 256 random directions by a set of 12 directions that are different from each other (and excluding situations in which these gradients would point along the same direction). The permutation table provides plenty of randomness so in practice it doesn't matter if these 12 vectors are predefined. Perlin in his 2002 paper decided to choose the following vectors:

$$ \begin{array}{l} (1,1,0),(-1,1,0),(1,-1,0),(-1,-1,0),\\ (1,0,1),(-1,0,1),(1,0,-1),(-1,0,-1),\\ (0,1,1),(0,-1,1),(0,1,-1),(0,-1,-1) \end{array} $$Though keep in mind that our permutation table returns integers in the range [0,255], so in order to choose one of these vectors randomly we would need to do something like P[Hash(x,y,z)] % 12 though as you know we don't like to use the modulo operator too much because it's slower than bitwise operators and it requires to handle negative values differently than positive values (bitwise operators fix this problem). To replace the modulo operator with a bitwise operator, Perlin proposes to extend the array of 12 vectors to 16 vectors, adding to the first 12 the following 4 directions:

$$ \begin{array}{l} (1,1,0),(-1,1,0),(0,-1,1), (0,-1,-1). \end{array} $$We already used these directions but Perlin claims that because the first 12 directions form a regular tetrahedron, adding some of these directions redundantly doesn't introduce any bias in the texture.

The splotchy like appearance is not as visible anymore (check out the comparaison image below). Implementing this change is actually quite simple. Our hash function returns numbers in the range [0,255] so we need to use another bitwise operator to set this number to the range [0,15].

We can move this code into its own function:

The image below shows a comparison between the original Perlin noise implementation (left) and the improved version (right):

While not being significantly different the two implementations give distinct results. The improved version creates vertical and horizontal lines though that you don't see in the orignal version. This due to the fact that in the improved version, the gradients are aligned along the xy, xz and yz planes. While the choice of a quintic function as interpolant definitely reduces the visual artefacts and can be called an improvement, we don't think using the predefined gradients over random gradients is necessarily a good thing. You can find the complete implementation of the improved version in the last chapter of this lesson.

## What's Next?

This concludes our lesson on Perlin noise. The lesson is quite extensive already but there is certainly a lot more to say about noise functions in general. First, there exists quite a few more ways of generating a procedural noise. Some other common methods are the **wavelet noise** (developed by Pixar) the **Gabor noise** and the **simplex noise** which is also a kind of noise developed by Ken Perlin. We will write lessons on each one of these techniques in the future.

Finally it is important to be able to judge the quality of noise implementation against others. How do we that? We already mentioned the qualities that a noise function should have although. Among these qualities the noise should have a distribution of frequencies as uniform as possible and yet still appear random and smooth. One way of finding out whether a given noise function fits this criteria is to analyse its output in frequency domain. We will also learn about this technique in a future lesson.

## How to Use the Noise Function?

A procedural noise function in general can be used for many things:

- Terrain: in this lesson, we just studied the implementation of the function itself, though we also showed how to use it to create something like a terrain. We haven't shown yet how to create terrains with really complex and realistic surface details using the noise function. We will show this technique in a separate lesson yet to be published.
- Water surfaces: it can also be used to simulate a water surface. By offsetting the the y coordinative of the input point, it is possible to animate the displaced surface like waves. This is simple technique that works well though there are better methods to simulate water surfaces.
- Cloud: it can also be used to add surface details to volumes such as cloud. We use the noise function in the lesson on volume rendering to simulate the appearance of various cloudy shapes.
- Texturing: finally it can be used of couse to add texture details to surfaces. It can be used to modulate any input of the shader such as the color, the specular, or add some bump to the surface of an object.
- Animation: the noise function can also be used to add some noise to animations. A typical use case for example is to add some noise to a camera animation to simulate some camera shakes.

## References

*Improving Noise*. Ken Perlin (2002)

*State of the Art in Procedural Noise Functions*. A. Lagae and al. (2010)