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

Post a reply to this message

Alexander Enzmann wrote in message <382898C4.3749B2AA@mitre.org>...
>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 found this out myself a few days ago while trying to write a Perlin noise
pattern.  My solution was to simply add a line that divides the sum by 2
before clamping.

Mark

Post a reply to this message

Mark Wagner wrote:
> 
> Alexander Enzmann wrote in message <382898C4.3749B2AA@mitre.org>...
> >Perhaps someone can shed a little light on the POV-Ray noise function.
> ...
> 
> I found this out myself a few days ago while trying to write a Perlin noise
> pattern.  My solution was to simply add a line that divides the sum by 2
> before clamping.
> 
> Mark

My interest is actually a little different.  I have a functioning noise
function - I wanted to be able to get the same type of distribution of
values that POV-Ray gets.  I made the assumption that POV-Ray had
implemented a 1/f noise function.  It doesn't.  Although I'm sure the
POV-Ray community will insist it is just fine, it isn't in accordance
with the characteristics of a solid noise function as described by
Perlin and Peachy.

Xander

Post a reply to this message

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

Gerald K. Dobiasovsky wrote in message <382b9791@news.povray.org>...
>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!


The problem here is with the specific precomputed table.  A different table
would give a different set of values, and it is possible to design a table
that gives the correct behavior.

Mark

Post a reply to this message

"Gerald K. Dobiasovsky" wrote:
> 
> Alexander Enzmann <xan### [at] mitreorg> wrote:
> > Perhaps someone can shed a little light on the POV-Ray noise function.
...
> 
> 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)

Ok - I won't bother looking at the earlier versions then.

> 
> 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!

After a little more examination, it turns out that while the Noise()
function has problems, the DNoise() function produces reasonable
results.

As before, looking at several million samples of DNoise(), the following
values are what I saw.  [I sampled the three components of DNoise()
separately.]

POV-Ray Min: -1.05242,-1.00514,-1.04398, Max: 0.964014,0.986572,0.988593
Mean: -0.0192643,-0.0158032,-0.0162188
Median: -0.0183217,-0.0144683,-0.0156189
Std Dev: 0.256747,0.254648,0.255912

There is a small negative bias in the results, but nowhere near the ones
for Noise().  In contrast, the equivalent Perlin function gave me the
following statistics:

Noise Min: -1,-0.994576,-1, Max: 1,0.989578,1
Mean: 0.000336202,0.000105581,0.000179304
Median: -0.000122128,-0.000618196,-0.000264098
Std Dev: 0.271045,0.27106,0.271046

These are basically close enough for texturing work.  So, what does it
affect in POV-Ray?  Functions that directly call Noise() are: Bozo,
Granite, Spotted, Bumps, Dents, Wrinkles, The functions that use
Turbulence() (based on Noise()) are: Marble, Agate, and Irid. 
Turbulence warps are based on DTurbulence() (which uses DNoise()).

> 
> 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.

Quite true.

> ...
> 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.

I'm not too sure about that.  Since a trilinear interpolation is
performed, I would think that the result would actually end up at 0 (no
turbulence).

Xander

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:

> The problem here is with the specific precomputed table.  A different
table
> would give a different set of values, and it is possible to design a table
> that gives the correct behavior.
>
> Mark
>
>

One would have to perform basic statistics tests on the numbers
in RTable, but for Alexander Enzmann's results they would have
to be heavily skewed towards negative values
(at least they _look_ pretty much evenly distributed).

And his tests of DNoise() - note his answer to my post - are much
more well behaved than Noise(), so maybe there's some "typo" bug
in Noise() like a wrong sign or something like that...

--
Gerald
ger### [at] aonat

Post a reply to this message

> These are basically close enough for texturing work.  So, what does it
> affect in POV-Ray?  Functions that directly call Noise() are: Bozo,
> Granite, Spotted, Bumps, Dents, Wrinkles, The functions that use
> Turbulence() (based on Noise()) are: Marble, Agate, and Irid.
> Turbulence warps are based on DTurbulence() (which uses DNoise()).

If I may be so bold as to stick my nose in here...

  Would this bias in Noise() manifest itself as "flat" areas in a Bozo
normal modifier
(i.e. would the high or low points of Bozo bumps appear shaved off)? If
this is indeed the case it would give me rest on something which has
puzzled me for a while.

Abe

Post a reply to this message

Abe <bul### [at] taconicnet> wrote:

> If I may be so bold as to stick my nose in here...

Why, this is an open forum,
not restricted to some "select" group of  hot shot programmers :)
(which I'm definitely _not_, just someone who started to poke
around in the POV source a little bit some time ago;
Mr. Enzmann ,BTW, plays in a different league
being the author of some parts of POV itself
and of all of the well-known Polyray raytracer).

>
>   Would this bias in Noise() manifest itself as "flat" areas in a Bozo
> normal modifier
> (i.e. would the high or low points of Bozo bumps appear shaved off)? If
> this is indeed the case it would give me rest on something which has
> puzzled me for a while.
>
> Abe

If you have access to povray.bugreports look at the thread started
by Ron Parker:
<37444591.0@news.povray.org>
(Re: Bozo "saturation" problem), May 20, 1999.

Noise() produces values in a broader range than [0,1],
but anything exceeding those limits gets clamped to either 0 or 1,
producing those "flat" patches.
With a bias towards negative values one would expect to see
more patches with value 0 than with value 1...

 --
Gerald
ger### [at] aonat

Post a reply to this message

Abe wrote:
> 
> > These are basically close enough for texturing work.  So, what does it
> > affect in POV-Ray?  Functions that directly call Noise() are: Bozo,
> > Granite, Spotted, Bumps, Dents, Wrinkles, The functions that use
> > Turbulence() (based on Noise()) are: Marble, Agate, and Irid.
> > Turbulence warps are based on DTurbulence() (which uses DNoise()).
> 
> If I may be so bold as to stick my nose in here...
> 
>   Would this bias in Noise() manifest itself as "flat" areas in a Bozo
> normal modifier

Yes.  Also broad areas of color at the bottom of the color map.

Xander

Post a reply to this message