<h2>turbulence function</h2>
<p>From my understanding, the turbulence in Perlin noise is to accumulate Perlin noise of different frequencies with different weights. Based on this understanding, the return value of turbulences should have the same range of color (or pixel).</p>
<p>However, in some implementations (<a href="https://raytracing.github.io/books/RayTracingTheNextWeek.html" rel="nofollow noreferrer">Ray Tracing: The Next Week</a>) the range of <a href="https://raytracing.github.io/books/RayTracingTheNextWeek.html#perlinnoise/introducingturbulence" rel="nofollow noreferrer">turbulence</a> doesn't match the range of [0, 1]</p>
<pre class="lang-cpp prettyprint-override"><code>double turb(const point3&amp; p, int depth=7) const {
    auto accum = 0.0;
    auto temp_p = p;
    auto weight = 1.0;

    for (int i = 0; i &lt; depth; i++) {
        accum += weight*noise(temp_p);
        weight *= 0.5;
        temp_p *= 2;
    }

    return fabs(accum);
}
</code></pre>
<p>The initial value of <code>weight</code> is 1, and the range of <code>noise</code> is [-1, 1]. So it is possible that after the first iteration, <code>accum</code> became 1, and the following iterations could make it larger than 1.</p>
<p>I also read through the related part in the <a href="https://dl.acm.org/doi/pdf/10.1145/325165.325247" rel="nofollow noreferrer">original paper</a>, however, the pseudocode seems very similar:</p>
<pre><code>function turbulence(p)
  t = 0
  scale = 1
  while (scale &gt; pixelsize)
      t += abs(Noise(p / scale) * scale)
      scale /= 2
  return t
</code></pre>
<p>And it seems like the color representation in Perlin's original paper is also in the range of [0, 1] according to the the following line:</p>
<blockquote>
<p>For example,
one possible pixel for the variable list [red green blue] is [0.5 0.3
0.7].</p>
</blockquote>
<p>So I'm wondering if the <code>turbulence</code> function is designed this way because of the extremely low probability of returning a value that is out of range. Or am I missing something?</p>
<h2>Noise function</h2>
<p>Also, the description of <code>Noise()</code> function in the original paper is pretty confusing. Perlin didn't explicitly write about the range of the returning value. But he used it this way:</p>
<blockquote>
<p>By evaluating Noise() at visible surface points of simulated objects we may create a simple &quot;random&quot; surface texture (figure Spotted.Donut) :
color = white * Noise(point)</p>
</blockquote>
<p>So I'm assuming it should be [0, 1] which make the expression <code>white * Noise(point)</code> in the range of [0, 1]</p>
<p>However, an <code>abs()</code> function is added in the <code>turbulence</code> function.</p>

CC BY-SA 4.0
2022-11-28T02:31:11.500Z
Would a starting weight of 0.5 make more sense ? It should accumulate to near one after several loops (e.g. 1/2 + 1/4 + 1/8 + 1/16, etc)
PaulHK
CC BY-SA 4.0
2022-11-28T04:03:42.920Z
@PaulHK I actually tried this before. I kept all implementations of Ray Tracing: The Next Week the same and changed the weight as you mentioned. But the output image will be significantly dimmer. And surprisingly, the original implementation never gives a return value that is greater than 1.
ttzytt
CC BY-SA 4.0
2022-11-28T06:19:23.160Z
Yes I've noticed that too with Perlin, I don't think the distribution of values is evenly distributed. This algorithm summing multiple of them together biases that distribution even further, depending on number of iterations.
PaulHK
<noise>
Confusion on the return value of turbulence of Perlin noise
ttzytt
# Confusion on the return value of turbulence of Perlin noise

(Asked by: username_0 on 2022-11-27)

## turbulence function

From my understanding, the turbulence in Perlin noise is to accumulate Perlin noise of different frequencies with different weights. Based on this understanding, the return value of turbulences should have the same range of color (or pixel).

However, in some implementations ([Ray Tracing: The Next Week](https://raytracing.github.io/books/RayTracingTheNextWeek.html)) the range of [turbulence](https://raytracing.github.io/books/RayTracingTheNextWeek.html#perlinnoise/introducingturbulence) doesn't match the range of [0, 1]

```cpp
double turb(const point3& p, int depth=7) const {
    auto accum = 0.0;
    auto temp_p = p;
    auto weight = 1.0;

    for (int i = 0; i < depth; i++) {
        accum += weight*noise(temp_p);
        weight *= 0.5;
        temp_p *= 2;
    }

    return fabs(accum);
}

```

The initial value of `weight` is 1, and the range of `noise` is [-1, 1]. So it is possible that after the first iteration, `accum` became 1, and the following iterations could make it larger than 1.

I also read through the related part in the [original paper](https://dl.acm.org/doi/pdf/10.1145/325165.325247), however, the pseudocode seems very similar:

```
function turbulence(p)
  t = 0
  scale = 1
  while (scale > pixelsize)
      t += abs(Noise(p / scale) * scale)
      scale /= 2
  return t

```

And it seems like the color representation in Perlin's original paper is also in the range of [0, 1] according to the the following line:

> For example,
> one possible pixel for the variable list [red green blue] is [0.5 0.3
> 0.7].

So I'm wondering if the `turbulence` function is designed this way because of the extremely low probability of returning a value that is out of range. Or am I missing something?

## Noise function

Also, the description of `Noise()` function in the original paper is pretty confusing. Perlin didn't explicitly write about the range of the returning value. But he used it this way:

> By evaluating Noise() at visible surface points of simulated objects we may create a simple "random" surface texture (figure Spotted.Donut) :
> color = white \* Noise(point)

So I'm assuming it should be [0, 1] which make the expression `white * Noise(point)` in the range of [0, 1]

However, an `abs()` function is added in the `turbulence` function.

**Tags:** noise

> **Comments:**
> **username_1**: Would a starting weight of 0.5 make more sense ? It should accumulate to near one after several loops (e.g. 1/2 + 1/4 + 1/8 + 1/16, etc)  
> **username_0**: @username_1 I actually tried this before. I kept all implementations of Ray Tracing: The Next Week the same and changed the weight as you mentioned. But the output image will be significantly dimmer. And surprisingly, the original implementation never gives a return value that is greater than 1.  
> **username_1**: Yes I've noticed that too with Perlin, I don't think the distribution of values is evenly distributed. This algorithm summing multiple of them together biases that distribution even further, depending on number of iterations.  

---

## 0 answers

