Alain <aze### [at] qwertyorg> wrote:

> > Alain<aze### [at] qwertyorg>  wrote:

> >>
> >>> camera {
> >>>
> >>>       #declare xS = 0;
> >>>       #declare yS = 1;
> >>>       #declare zS = 0;
> >>>       up<xS,yS,zS>
> >>>       right x*image_width/image_height
> >>>
> >>>       angle 1
> >>>       location<0,0,-2000>
> >>>       look_at (Position - 9*x)
> >>> }
> >>> .....
> >>> light_source {                    // far enough to avoid problems ...
> >>>     0
> >>>     color White
> >>>     translate<20000, 30000, -10000>
> >>> }
> >>>
> >>> For zCam<= -1958.5 or zCam>= 2003.5, all the defects in my scene (where there
> >>> are other SORs, affected by the same problem) are gone.
> >>>
> >>> Gilles
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> You place your camera at a large distance and use a very small angle
> >> that effectivelt removes perspective. That, in turn, can cause
> >> calculation errors. Those errors will cause the apearance of various
> >> artefacts.
> >>
> >> Try placing your camera closer and use the orthographic projection. It
> >> effectively simulate a camera set at infinity.
> >>
> >>
> >> Alain
> >
> >
> > I can imagine that (this is also a reply to Warp) floating point has a limiting
> > accuracy, which may be critical when you deal with infinitely thin (right ?)
> > surfaces like SOR.
> > Of course, without looking at the algorithm, one cannot say more ...
> > I am nevertheless slightly amazed by the fact that the defect vanish when you
> > move the camera closer or FARTHER from the object ...
> >
> > Gilles
> >
> >
> >
>
> That's the problem with floating numbers. There are situations where
> they introduce some random noise in the results, while, at other times,
> you get exact results.
>
> If you appen to work with values that can be represented exactly within
> the precision available, all is well. If, at least some values can't be
> represented exactly in binary, then you get rounding errors.
> If you use very small values with large ones, or very large with small,
> you get precision and underflow errors in addition to the rounding ones.
>
> You can also notice that the defects will move, change or vanish totaly
> if you rotate your object, or rotate the camera around it, while keeping
> the same distance.
>
> Also, in your case, if you scale the object, the result WILL change.
>
>
> Alain

That's true ... sigh ...
I remember the good old times of the double and triple precision specifications
....
.... which did not prevent you from running into problems to be handled, at some
point !
Gilles

Post a reply to this message

> I wonder how the rendering of the SOR can vary with the distance of the
> observer,
> and, more specifically, be wrong only within a certain interval of
> distances/orientations ...
> At first sight, it seems that this happen when the axis of the SOR is ~
> perpendicular to the view ray, and, then, within a certain interval of observing
> distances.
> At first sight ...

I guess there might be a similar root cause as with sphere sweeps; 
there, POV-Ray does not try to solve for the intersection points 
diectly, but rather first solves for the "time coordinates" along the 
sphere_sweep spline correlating which any intersections, and then 
computes the 3D coordinate of the respective intersection by computing. 
This approach doesn't work well at places where multiple intersections 
correspond to the same "time coordinate", but unfortunately we currently 
lack the qualification and/or available time to sort these things out.

You might want to try a lathe object instead of SOR.

Post a reply to this message