RC3, SuSE Linux 7.3, P3 600, 128MB RAM

When I use values for turbulence above 2^31 (2 billions), white areas 
appear. The bigger the values the bigger the areas. The following scene 
shows the 'problem':


camera{orthographic location z * -10 look_at 0 right x * 8 up y * 6}
plane
   {
   -z, 0
   pigment
      {
      checker color rgb 1 color rgb 0
      warp
         {
         turbulence 10000000000
         }
      }
   finish{ambient 1}
   }


I don't know if it's possible or even worth to fix it, but such high 
values could perhaps be used for some noise in only one direction. 
Maybe using some floating point type instead of int would solve the 
problem and be also more accurate.
-- 
Felix Wiemann

Post a reply to this message

On Mon, 06 May 2002 15:42:53 +0200, Felix Wiemann <Fel### [at] gmxnet>
wrote:
> Maybe using some floating point type instead of int

Turbulence has neither float nor integer as parameter.
It use vector parameter! Shortcut with float as vector
is first example of 6.7.12.6.3 chapter.  I wonder what
suggested to you it should be integer ?

ABX

Post a reply to this message

> On Mon, 06 May 2002 15:42:53 +0200, Felix Wiemann
> <Fel### [at] gmxnet> wrote:
>> Maybe using some floating point type instead of int
> 
> Turbulence has neither float nor integer as parameter.
> It use vector parameter! Shortcut with float as vector
> is first example of 6.7.12.6.3 chapter.  I wonder what
> suggested to you it should be integer ?

Sorry, I haven't been clear enough. I actually refered to the source. I 
guess it's a problem of int (or long int) due to the 2^31 limit.
-- 
Felix Wiemann

Post a reply to this message

Felix Wiemann <Fel### [at] gmxnet> wrote:
> When I use values for turbulence above 2^31 (2 billions), white areas 
> appear.

  And that surprises you?
  When we go to the extremes, floating point accuracy errors usually give
funny results.

> Maybe using some floating point type instead of int would solve the 
> problem and be also more accurate.

  Why do you think that any part of turbulence calculations use ints? AFAIK
it's all floating point.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On Mon, 06 May 2002 16:59:10 +0200, Felix Wiemann <Fel### [at] gmxnet>
wrote:
> Sorry, I haven't been clear enough. I actually refered to the source. I 
> guess it's a problem of int (or long int) due to the 2^31 limit.

IIRC every number is readed from scripts as float. Only if internal
representation requires integer then it is converted.

ABX

Post a reply to this message

Warp wrote:
>   And that surprises you?
>   When we go to the extremes, floating point accuracy errors usually
>   give
> funny results.

At exactly 2^31?

>   Why do you think that any part of turbulence calculations use ints?
>   AFAIK
> it's all floating point.

Because this is a limit typical for int.
-- 
Felix Wiemann

Post a reply to this message

In article <3cd69991@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Why do you think that any part of turbulence calculations use ints? AFAIK
> it's all floating point.

Noise uses ints and noise is used by turbulence.  However, your point is of
course still valid - using numbers of this size will never yield a precise
enough result.  Nor is there really any use for such a turbulence value.

    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

In article <3cd6875a@news.povray.org> , Felix Wiemann <Fel### [at] gmxnet>
wrote:

> I don't know if it's possible or even worth to fix it, but such high
> values could perhaps be used for some noise in only one direction.

No, what you are trying is close to pointless.  It will break very early along
the way - even long before this limit!  Of course, if you really want to be
floating-point accuracy (which is the issue long before hitting this
particular limit) to be part of your turbulence you can use it.

    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

Another simple example of where accuracy errors kick in is the
following:

camera { location -z*100000 look_at 0 angle .002 }
light_source { <100,200,-300>, 1 }
sphere { 0,1 pigment { rgb 1 } }

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message