Alexander Enzmann <xan### [at] mitreorg> wrote:
> Perhaps someone can shed a little light on the POV-Ray noise function.
> Looking at the code, towards the bottom of the function Noise(...),
> there is:
>
>   sum = sum + 0.5; /* range at this point -0.5 - 0.5... */
>
>   if (sum < 0.0)
>     sum = 0.0;
>   if (sum > 1.0)
>     sum = 1.0;
>
> However, in attempts to get a distribution of values that come close to
> the POV-Ray noise function out of a standard Perlin noise function, I
> found that there is a problem.
>
> I took several million samples of the noise function in a box with sides
> of length 1000. These are the basic statistics for POV-Ray's Noise(),
> before adding the 0.5 and clamping to the range [0,1]:
>
> Min, max: -1.05242, 0.988997
> Mean: -0.0191481, Median: -0.535493, Std Dev: 0.256828
>
> Clearly, the range of values for sum is not -0.5 to 0.5 as suggested in
> the code.  In fact, since the median value is less than -0.5, the actual
> Noise() returns 0.0 more than half of the time (after adding 0.5 and
> clamping).  Doesn't make sense.
>
> Compare the above to a traditional Perlin solid noise function, which
> for the same set of sample points yields:
>
> Min, max: -0.6746, 0.672579
> Mean: -0.000140859, Median: 0.0487365, Std Dev: 0.180682
>
> As would be expected, the values are centered around 0.  Another
> interesting point is that the standard deviation for the POV-Ray noise
> function is not even close to the Perlin noise.
>
> I'll have to go digging around and see if I can find the way POV-Ray
> used to compute the solid noise function (using a CRC table, giving a
> machine dependent result) and see if it had similar characteristics.  In
> any case, this really looks abnormal.
>
> Xander


The basic algorithm doesn't seem to have changed since DKB,
but since POV 3.0 the random float table exists precomputed in
"texture.c" rather than being calculated from a CRC table after startup.
(The range of the numbers in the table is -1.0 < # < 1.0)

I am surprised your results are shifted towards negative values.
Looking at the algorithm used
(at least as I understand it, or, rather, I believe I understand it :) )
one would expect its range to be bigger than -0.5 to 0.5,
but still with a symmetrical distribution about 0.0!

Contrary to (AFAIK) Perlin noise the random vectors at the integer
lattice points in POV are not of unit length,
but are in the range of -sqrt(3) to sqrt(3), because the vectors are
built by simply assigning each component a value from the random number
table.

After computing the dot product another table value * 0.5 is added to the
result (Peachey calls this hybrid method "Value-Gradient Noise" in the
"Texturing and Modelling" book).

The extreme case (point at the center of a lattice cell, all random vectors
having maximum possible length _and_ looking exactly to the cell's
center or away from it _and_ the scalars that get added all having the
same sign as the dot products) would return +/-2.0 before adding 0.5
and clamping.

Not exactly what the documentation says,
but in the light of your findings something else seems to be wrong
with Noise(), too.

--
Gerald
ger### [at] aonat

Post a reply to this message