I just decided to implement some new pattern and stepped over 
the following in pattern.cpp:

/*****************************************************************************
* FUNCTION
*   radial_pattern
[..]
* RETURNS
*   DBL value in the range 0.0 to 1.0
******************************************************************************/

static DBL radial_pattern (VECTOR EPoint)
{
  register DBL value;

  if ((fabs(EPoint[X])<0.001) && (fabs(EPoint[Z])<0.001))
  {  value = 0.25;  }
  else
  {  value = 0.25 + (atan2(EPoint[X],EPoint[Z]) + M_PI) / TWO_M_PI;  }

  return(value);
}

Since atan2() will return values in range -Pi..Pi, the return value 
of the pattern will be in range 0.25 .. 0.25+2*Pi and not in range 
0..1 as stated in the description of the function. 

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> Since atan2() will return values in range -Pi..Pi, the return value
> of the pattern will be in range 0.25 .. 0.25+2*Pi and not in range
>
Grbml... I mean 0.25 .. 1.25, i.e. 0.25 + 2*Pi/(2*Pi). -Sigh-

Wolfgang

Post a reply to this message

In article <403c951a@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
wrote:

> static DBL radial_pattern (VECTOR EPoint)
> {
>   register DBL value;
> 
>   if ((fabs(EPoint[X])<0.001) && (fabs(EPoint[Z])<0.001))
>   {  value = 0.25;  }
>   else
>   {  value = 0.25 + (atan2(EPoint[X],EPoint[Z]) + M_PI) / TWO_M_PI;  }
> 
>   return(value);
> }
> 
> Since atan2() will return values in range -Pi..Pi, the return value 
> of the pattern will be in range 0.25 .. 0.25+2*Pi and not in range 
> 0..1 as stated in the description of the function. 

Note that the code adds pi to atan2() and divides the result by 2*pi 
before adding the 0.25. So the range of the function is [0.25, 1.25]...I 
don't know why. It gets wrapped to [0, 1] later anyway...maybe it was 
done to make the pattern start at +x. Seems unnecessary to me, but 
changing it would affect every scene that uses radial. Though you could 
make it dependent on version.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:

> In article <403c951a@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> static DBL radial_pattern (VECTOR EPoint)
>> {
>>   register DBL value;
>> 
>>   if ((fabs(EPoint[X])<0.001) && (fabs(EPoint[Z])<0.001))
>>   {  value = 0.25;  }
>>   else
>>   {  value = 0.25 + (atan2(EPoint[X],EPoint[Z]) + M_PI) / TWO_M_PI;  }
>> 
>>   return(value);
>> }
>> 
>> Since atan2() will return values in range -Pi..Pi, the return value
>> of the pattern will be in range 0.25 .. 0.25+2*Pi and not in range
>> 0..1 as stated in the description of the function.
> 
> Note that the code adds pi to atan2() and divides the result by 2*pi
> before adding the 0.25. So the range of the function is [0.25, 1.25]...
>
[ Note that I corrected this mistake of mine about 3.5 hours before your 
post :) ]

> I don't know why. It gets wrapped to [0, 1] later anyway...maybe it was
> done to make the pattern start at +x. Seems unnecessary to me, but
> changing it would affect every scene that uses radial. Though you could
> make it dependent on version.
> 
Well, but instead of adding 0.25 one could use atan2(z,-x) instead of 
atan2(x,z). Why not write: 

value = (atan2(EPoint[Z],-EPoint[X]) + M_PI) / TWO_M_PI;

Now, the values are back in range 0..1 and it behaves exactly like 
the current one (after being wrapped to 0..1). 

Wolfgang

Post a reply to this message

In article <403cf5a2@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> [ Note that I corrected this mistake of mine about 3.5 hours before your
> post :) ]

And note that your clock is one hour behind the real-world :-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> In article <403cf5a2@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> [ Note that I corrected this mistake of mine about 3.5 hours before your
>> post :) ]
> 
> And note that your clock is one hour behind the real-world :-)
> 
Oh, yeah... correct. Just installed debian "sid" yesterday. 

The issue is "hardware clock stores UTC" vs "hwclock stores local time". 
I noticed that yesterday when going to bed 1 hour too late :p
...and forgot to adjust it today. 

Wolfgang

Post a reply to this message