You're dealing with two numbers, one of them being approximately 20 
million times the other.  It's a known aspect of the hardware we use 
that you should keep your ratios smaller than this to avoid precision 
errors.  It's the same reason you shouldn't try to model the solar 
system with physically accurate sizes and positions.

You'd think that a double precision float would be able to handle more 
than this, since the difference between the two is only 20 bits, but 
apparently this is the limit.

...Chambers

Post a reply to this message

> You'd think that a double precision float would be able to handle more 
> than this, since the difference between the two is only 20 bits, but 
> apparently this is the limit.

Oh yeah, I guess it uses doubles in there too, maybe 3.7 will be more
accurate? (probably not though... but maybe the 64 bit version
eventually?)

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> You're dealing with two numbers, one of them being approximately 20
> million times the other.  It's a known aspect of the hardware we use
> that you should keep your ratios smaller than this to avoid precision
> errors.  It's the same reason you shouldn't try to model the solar
> system with physically accurate sizes and positions.
>
> You'd think that a double precision float would be able to handle more
> than this, since the difference between the two is only 20 bits, but
> apparently this is the limit.
>
> ...Chambers

I'm not sure where the 20 mil comes in - the coordinates are around
1million.
Can you explain the 20mil?

And, yes, I was told originally that POV uses doubles for the raytracing,
tho single precision for some bits.
Anyway, I am deliberately testing at increasing distances from origin 150,
1000, 10,000 , 100,000 etc all the way up to 2mil.

Anyway, I'm after insight into the actual sphere rendering algorithm: I know
the floating point error is what causes the problem but I want to know why
it happens in this peculiar way - all the other rendering just gets more
inaccurate gracefully (as described in the paper below).
FYI, I put the results into this paper:
http://planet-earth.org/ubcw/thorne-UBCW.pdf


chris

Post a reply to this message

"Tim Attwood" <tim### [at] comcastnet> wrote:
> > You'd think that a double precision float would be able to handle more
> > than this, since the difference between the two is only 20 bits, but
> > apparently this is the limit.
>
> Oh yeah, I guess it uses doubles in there too, maybe 3.7 will be more
> accurate? (probably not though... but maybe the 64 bit version
> eventually?)

Yes doubles should be able to handle it. you can use doubles for greater
than radius of the earth (~6.4mil) - and that is more than the 1mil units I
used here.

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> Floating point is implemented as single precision (4 byte) numbers in
> POV.

  Certainly not true.

-- 
                                                          - Warp

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> You're dealing with two numbers, one of them being approximately 20 
> million times the other.  It's a known aspect of the hardware we use 
> that you should keep your ratios smaller than this to avoid precision 
> errors.

  Where exactly are you getting that number?

> You'd think that a double precision float would be able to handle more 
> than this, since the difference between the two is only 20 bits, but 
> apparently this is the limit.

  This is not a question of floating point accuracy limit. This is a
question of a deliberate limit.

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> Oh yeah, I guess it uses doubles in there too, maybe 3.7 will be more
> accurate?

  Why would 3.7 be more accurate? It uses the same data types.

> (probably not though... but maybe the 64 bit version
> eventually?)

  64-bitness has no effect whatsoever on floating-point calculations
(their size has not changed in the 64-bit AMD/Intel processors).

-- 
                                                          - Warp

Post a reply to this message

You are most probably hitting the internal limit set in POV-Ray for
distances.

  POV-Ray uses a deliberate limit. If an intersection point is farther
away than this limit, it's ignored.

  There are many reasons for setting up this kind of limit, one of which
is to prevent the program from misrendering objects due to floating point
inaccuracies. Granted, I think that limit could be made larger without
any accuracy problems showing up, at least not with most primitives.

-- 
                                                          - Warp

Post a reply to this message

dragonmage wrote:
> Anyone have insight into the actual part of the calculation that is failing?

There is no failure. The implementation is designed with certain limits for
the maximum and minimum intersection distances. This is necessary as
precision is finite and very large as well as very small numbers will
accumulate increasingly visible inaccuracies as they flow through the
intersection computations. Keep your scene within 10e7 to 10e-5 and you will
be fine for most object types.

	Thorsten, POV-Team

Post a reply to this message

Tim Attwood nous apporta ses lumieres en ce 20-03-2007 04:11:
>> You'd think that a double precision float would be able to handle more 
>> than this, since the difference between the two is only 20 bits, but 
>> apparently this is the limit.

> Oh yeah, I guess it uses doubles in there too, maybe 3.7 will be more
> accurate? (probably not though... but maybe the 64 bit version
> eventually?)


Version 3.7 use double precision the same way as version 3.6, 3.1 and previous. 
64 bits processors still use the 64 (80 internal = double and half precision) 
bits FPU used in previous 32 bits CPU, even 16 bits BPU used, then external, 64 
bits FPU.
You need 128 bits FPU (quad precision) to realy exeed actual precision limitations.

-- 
Alain
-------------------------------------------------
Getting the job done is no excuse for not following the rules.

Post a reply to this message