There seems to be a bug in the various noise functions. It exhibits itself as
banding after a certain _negative_ distance, along any axis, from the origin.
This distance varies depending on the noise function: it is around 78.125 for
1/f noise (granite), 312.5 (78.125*4) for DNoise and Agate noise, and around
10000 for Perlin noise (bozo, bumps, spotted).
Furthermore, in 1/f and DNoise the bug seems to become more pronounced at
78.125*2 and 78.125*4

Versions: POVWin 3.1g (Watcom and VC compile), POV Superpatch (3.1e codebase).
The problem was also reported to exist on 3.01r1.watcom

System: Celeron, 128MB RAM, Win98

//BEGIN EXAMPLE SCENE

camera{
    orthographic
    location y*5
    up y*5*.75 right x*5
    look_at 0
}

//1/f noise (granite)
#declare Tex1=
pigment{
    granite
    color_map{[0 rgb 0][1 rgb 1]}
    translate 78.13*x //First signs of banding
    //translate 156.25*x //More pronounced
    //translate 312.5*x //Even more pronounced
    scale 5
}

//Perlin noise (Bozo & Bumps & Spotted)
#declare Tex2=
pigment{
    bozo
    color_map{[0 rgb 0][1 rgb 1]}
    translate 10000*x
    scale 1
}

//DNoise (turbulence)
#declare Tex3=
pigment{
    gradient x
    color_map{[0 rgb 0][1 rgb 1]}
    translate 312.5*x //Banding starts
    //translate 625*x //Becomes more pronounced
    scale 1
    turbulence 1
}

//Agate turbulence
#declare Tex4=
pigment{
    agate
    color_map{[0 rgb 0][1 rgb 1]}
    translate 312.5*x //Banding starts
    scale 5
}


plane{
    y,0
    pigment{Tex1}
    finish{ambient 1}
}

Post a reply to this message

Margus Ramst wrote:

> Versions: POVWin 3.1g (Watcom and VC compile), POV Superpatch (3.1e codebase).
> The problem was also reported to exist on 3.01r1.watcom

It is also now reported to be evident in Pov v2.2.ibmibc copyright date 1993.
If it is a bug it has existed for quite some time now.

-- 
Ken Tyler

Post a reply to this message

I do not consider a precision problem a bug.
  You always choose a precision deliberately while bugs are unintentional.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Wed, 25 Aug 1999 13:57:01 +0300, Margus Ramst wrote:
>There seems to be a bug in the various noise functions. It exhibits itself as
>banding after a certain _negative_ distance, along any axis, from the origin.
>This distance varies depending on the noise function: it is around 78.125 for
>1/f noise (granite), 312.5 (78.125*4) for DNoise and Agate noise, and around
>10000 for Perlin noise (bozo, bumps, spotted).
>Furthermore, in 1/f and DNoise the bug seems to become more pronounced at
>78.125*2 and 78.125*4

The problem is in texture.c, at the top:

/* Ridiculously large scaling values */

|#define MINX (-10000)
|#define MINY MINX
|#define MINZ MINX

The noise function only works in positive domains, so it first translates 
your coordinate by -<MINX, MINY, MINZ> before computing noise.  As you can 
see, this breaks at -10000.  Granite breaks at such a low offset because of 
this:

|  VScale(tv1,EPoint,4.0);
|
|  for (i = 0; i < 6 ; freq *= 2.0, i++)
|  {
|    VScale(tv2,tv1,freq);
|    temp = 0.5 - Noise (tv2);

As you can see, your sample point will be scaled by up to a factor of 128.
Surprise, surprise: 10000/128=78.125.  Obviously, the larger your sample 
point is, the more iterations of the 1/f code will be over 10000.  If you
determined this by experimentation, I'm impressed. :)

The fix is clearly to modify MINX and recompile.  Why it's set so low is 
anybody's guess.

Post a reply to this message

On 25 Aug 1999 09:38:07 -0400, Ron Parker wrote:
>The fix is clearly to modify MINX and recompile.  Why it's set so low is 
>anybody's guess.

Silly me, I should read all the groups before I respond to a post in 
.bugreports. :)

A workaround, obviously, is to translate your texture to somewhere 
positive.

Post a reply to this message