I am having trouble rendering scenes on a large scale, where the distances
and sizes are millions of units. Here is a test case that should draw the
same image for every frame, since all positions and sizes are interms of
'm', but in fact shows the sphere shrinking as clock increases from 0 to 1:

#declare m = 980000+130000*clock;
#declare camera_pos = <0,0,1>*m;
#declare sphere_pos = camera_pos + x*10*m;
camera { location camera_pos look_at sphere_pos }
sphere { sphere_pos, 1*m texture { pigment { color rgb 1 } finish { ambient
1 }}}

I remember from old forays into the POV code that weird things happen when
object sizes/volumes approach HUGE_VAL and related constants. Is that the
problem here?
Should I submit a patch if I can improve the situation?

I am running POV-Ray 3.6.1 on Linux 2.6.17-mm6 with an Athlon processor.
The binary was compiled from unpatched source.

Thanks for any advice.

-Eric

Post a reply to this message

"Eric Buddington" <ebu### [at] wesleyanedu> wrote:
> I am having trouble rendering scenes on a large scale, where the distances
> and sizes are millions of units.
>
Problem is probably floating-point number accuracy.

http://tag.povray.org/povQandT/languageQandT.html#largescaleproblems

Post a reply to this message

"Nicolas Alvarez" <nic### [at] gmailrockscom> wrote:
> "Eric Buddington" <ebu### [at] wesleyanedu> wrote:
> > I am having trouble rendering scenes on a large scale, where the distances
> > and sizes are millions of units.
> >
> Problem is probably floating-point number accuracy.
>
> http://tag.povray.org/povQandT/languageQandT.html#largescaleproblems

If you replace the sphere object with an equivalent 'isosurface sphere'
the scene from Eric and the demo scene from
http://tag.povray.org/povQandT/languageQandT.html#largescaleproblems
do not show any problems.

Is there a problem with sphere objects?

(I would like HUGE_VAL to be removed from the source code too, because
it seems to be an arbitrary limit, and _relative_ precision should be
looked at instead IMHO).

Post a reply to this message

"Nicolas Alvarez" <nic### [at] gmailrockscom> wrote:
> "Eric Buddington" <ebu### [at] wesleyanedu> wrote:
> > I am having trouble rendering scenes on a large scale, where the distances
> > and sizes are millions of units.
> >
> Problem is probably floating-point number accuracy.
>
> http://tag.povray.org/povQandT/languageQandT.html#largescaleproblems

Excellent - I hadn't seen this discussion before. I can't quite figure how
(in the FAQ's example) a distance of 10^5 is enough to cause these
artefacts, though I can  certainly see how you can lose lots of precision
subtracting two floats of nearly equal magnitude.

I'm certainly more willing to accept the necessity of HUGE_VAL, given this.
It really destroys the options for cosmic-scale rendering, though.

-Eric

Post a reply to this message

> I'm certainly more willing to accept the necessity of HUGE_VAL, given
> this. It really destroys the options for cosmic-scale rendering,
> though.
Not really: often, just making your units represent a greater real-world
distance will fit your scene into a reasonable range. There's just as
much precision on the small side of 1 as the large side, so divide all
your distances by 10^5 and you should be fine.

-- 
There is no such thing as a small specification change.
http://surreal.istic.org/                             God save the King!

Post a reply to this message

Eric Buddington <ebu### [at] wesleyanedu> wrote:
> I can't quite figure how
> (in the FAQ's example) a distance of 10^5 is enough to cause these
> artefacts

  It's not the distance alone. It's in conjunction with the really small
camera angle. Even though alone both numbers are very accurate in 64-bit
floating point representation, when they are combined and the results
used for the ray-sphere intersection calculations, the inaccuracies
start showing themselves.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Eric Buddington <ebu### [at] wesleyanedu> wrote:
> > I can't quite figure how
> > (in the FAQ's example) a distance of 10^5 is enough to cause these
> > artefacts
>
>   It's not the distance alone. It's in conjunction with the really small
> camera angle. Even though alone both numbers are very accurate in 64-bit
> floating point representation, when they are combined and the results
> used for the ray-sphere intersection calculations, the inaccuracies
> start showing themselves.
>
> --
>                                                           - Warp

I am sorry to disturb
but when you replace the sphere with an isosurface, there is no problem.

Explicitly replacing

camera { location -z*1e5 look_at 0 angle .002 }
light_source { <10,20,-30>, 1 }
sphere { 0,1 pigment { rgb 1 } }

with even

camera { location -z*1e10 look_at 0 angle 0.00000002 }
//camera { location -z*1e5 look_at 0 angle .002 }
light_source { <10,20,-30>, 1 }
isosurface {
  function {sqrt(x*x + y*y + z*z) - 1}
  threshold 0 contained_by {box {<-1,-1,-1>, < 1, 1, 1>}} open
  pigment { rgb 1 }
} // end of isosurface -----------------------------------------

did not show the rendering problem from the original scene.

So how do you think this replaced scene is calculated with higher precision?

IMHO it shows that something is lets say not optimal in the current
implementation of POV-Ray. I can't say exactly what, that would require
source code analysis.

Post a reply to this message

> Warp <war### [at] tagpovrayorg> wrote:
> > Eric Buddington <ebu### [at] wesleyanedu> wrote:
> > > I can't quite figure how
> > > (in the FAQ's example) a distance of 10^5 is enough to cause these
> > > artefacts
> >
> >   It's not the distance alone. It's in conjunction with the really small
> > camera angle. Even though alone both numbers are very accurate in 64-bit
> > floating point representation, when they are combined and the results
> > used for the ray-sphere intersection calculations, the inaccuracies
> > start showing themselves.
> >
> > --
> >                                                           - Warp
>
> I am sorry to disturb
> but when you replace the sphere with an isosurface, there is no problem.
>
> Explicitly replacing
>
> camera { location -z*1e5 look_at 0 angle .002 }
> light_source { <10,20,-30>, 1 }
> sphere { 0,1 pigment { rgb 1 } }
>
> with even
>
> camera { location -z*1e10 look_at 0 angle 0.00000002 }
> //camera { location -z*1e5 look_at 0 angle .002 }
> light_source { <10,20,-30>, 1 }
> isosurface {
>   function {sqrt(x*x + y*y + z*z) - 1}
>   threshold 0 contained_by {box {<-1,-1,-1>, < 1, 1, 1>}} open
>   pigment { rgb 1 }
> } // end of isosurface -----------------------------------------
>
> did not show the rendering problem from the original scene.
>
> So how do you think this replaced scene is calculated with higher precision?
>
> IMHO it shows that something is lets say not optimal in the current
> implementation of POV-Ray. I can't say exactly what, that would require
> source code analysis.

Perhaps; I assume all these problems arise not from running out of exponent
range, but from doing addition/subtraction on values of very different
magnitudes, thereby running out of precision in the mantissa (adding 1 to
1e100 probably won't change it at all). Some such cases can be solved by
reordering floating-point operations, but that would require some
thoughtful code analysis.

Post a reply to this message