Hi, I have been testing the effects of translating a scene away from the
origin.
When I get to around 1million units, spheres get truncated in a strange way:
they are drawn either hemispherical or quarter spherical. Looking at
Spheres.cpp gives me no clue as to the cause - nothing obvious.

The truncation is not z buffer clipping or due to other objects in the scene
(a plane) as far as I can determine. I suspect that the displacement is
introducing enough error into the program that some part of the
calculations do not render some quarters of the spheres.

Anyone have insight into the actual part of the calculation that is failing?

Image and pov file are here:

http://www.planet-earth.org/SpheresStressTest1Mil.pov
http://www.planet-earth.org/SpheresStressTest1Mil.jpg

Post a reply to this message

> Anyone have insight into the actual part of the calculation that is 
> failing?
Floating point is implemented as single precision (4 byte) numbers in
POV. This translates into about a 7 digit decimal significand.

Your test code uses numbers with an 8 and 9 digit significands.

Post a reply to this message

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