> 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