This scene, which has a far away camera, creates artifacts in the torus:

// The /100 and *100 things move the camera away, closer to orthographic.
// Remove them and the problem disappears.
// Change them to 1000 and you'll notice a very strange pattern.
camera {
 right 1.3333*x/2  /100
 up y/2     /100

 location -15*z  *100
 look_at z

 // switching to the equivalent orthographic camera doesn't solve the
problem;
 // the farther away the camera is, the worse the artifacts get.
 /*
 orthographic
 location -z*1000
 right 1.3333*x*7.5
 up y*7.5
 look_at 0
 */
}

light_source {
 <.5,.7,-1>*9999
 rgb 1
}

torus {
 1,.5
 rotate 90*x
 pigment {rgb 1}
}

Render the scene at 320 x 240 with or without AA.

Beta 6, Win 98, PIII 900, 256 MB RAM

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

"Slime" <noo### [at] hotmailcom> wrote in message
news:3bd73981$1@news.povray.org...
> This scene, which has a far away camera, creates artifacts in the torus:

After trying this scene myself, I've discovered the light position doesn't
matter to the results and that the artifacts increase proportionally with
the distance of the camera.  As the distance increases, the artifacts start
appearing from the inner, then outer edge, working towards each other.  One
idea that may be the cause is a rounded sight vector from the camera through
the screen into the object if the decimals are being dropped with the small
angle camera.

PovRay 3.5b6
P200 Win2k SP2 256Mb RAM

N Shomber

Post a reply to this message

On Wed, 24 Oct 2001 17:56:41 -0400, "Slime" <noo### [at] hotmailcom>
wrote:

>This scene, which has a far away camera, creates artifacts in the torus:

Seems like an error in floating point precision / roundoff that
boggles the torus equation root solver. Try using the 'sturm' keyword
in your torus definition. If that doesn't help, you'll have to
represent the torus in another way - by a mesh, patches, or an
isosurface with a low accuracy.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Yeah, sturm didn't help.

Is it just me, or is POV-Ray 3.5 a *lot* more sensitive to floating point
precision errors? I never had to pay attention in 3.1... I could use numbers
like .0000001 or so before things started messing up.

Incidentally, this problem doesn't occur with other simple primitives.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

"Peter Popov" <pet### [at] vipbg> wrote in message
news:dndfttovfr9m0id8qibdnu18a8jj8aklnf@4ax.com...
> On Wed, 24 Oct 2001 17:56:41 -0400, "Slime" <noo### [at] hotmailcom>
> wrote:
>
> >This scene, which has a far away camera, creates artifacts in the torus:
>
> Seems like an error in floating point precision / roundoff that
> boggles the torus equation root solver. Try using the 'sturm' keyword
> in your torus definition. If that doesn't help, you'll have to
> represent the torus in another way - by a mesh, patches, or an
> isosurface with a low accuracy.
>
>
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] vipbg
> TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Wed, 24 Oct 2001 17:56:41 -0400, "Slime" <noo### [at] hotmailcom>
wrote:

>This scene, which has a far away camera, creates artifacts in the torus:

I have reported this for MegaPOV months ago and for 3.5.

http://news.povray.org/povray.beta-test/18702/
http://news.povray.org/povray.beta-test.binaries/18705/

not I not use extreme high values and use sturm
I think it is connected with ortho view

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

Wasn't it Slime who wrote:
>Yeah, sturm didn't help.
>
>Is it just me, or is POV-Ray 3.5 a *lot* more sensitive to floating point
>precision errors? I never had to pay attention in 3.1... I could use numbers
>like .0000001 or so before things started messing up.
>
>Incidentally, this problem doesn't occur with other simple primitives.

The example scene you posted exhibits exactly the same problem in v3.1.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Mike Williams" wrote
> Wasn't it Slime who wrote:
> >Yeah, sturm didn't help.
> >
> >Is it just me, or is POV-Ray 3.5 a *lot* more sensitive to floating point
> >precision errors? I never had to pay attention in 3.1... I could use
numbers
> >like .0000001 or so before things started messing up.
> >
> >Incidentally, this problem doesn't occur with other simple primitives.
>
> The example scene you posted exhibits exactly the same problem in v3.1.
>

It also happens in POV 1.1 on the Amiga at closer distances under the
maximum distance. It's a pretty old problem.  Computers just don't have
infinite accuracy.

N Shomber

Post a reply to this message

Well, it makes sense that it may happen when the rays have extremely low
slopes (that is, they go over 1 unit in the X direction for every 100000 or
so units in the Z direction), but why does it happen with an orthographic
camera? At only a distance of about 1000 units? Surely POV can handle more
than four decimals.

--
- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]
"N Shomber" <nsh### [at] hotmailcom> wrote in message
news:3bd9f6ff@news.povray.org...
>
> "Mike Williams" wrote
> > Wasn't it Slime who wrote:
> > >Yeah, sturm didn't help.
> > >
> > >Is it just me, or is POV-Ray 3.5 a *lot* more sensitive to floating
point
> > >precision errors? I never had to pay attention in 3.1... I could use
> numbers
> > >like .0000001 or so before things started messing up.
> > >
> > >Incidentally, this problem doesn't occur with other simple primitives.
> >
> > The example scene you posted exhibits exactly the same problem in v3.1.
> >
>
> It also happens in POV 1.1 on the Amiga at closer distances under the
> maximum distance. It's a pretty old problem.  Computers just don't have
> infinite accuracy.
>
> N Shomber
>
>

Post a reply to this message

Slime wrote in message <3bd9faea$1@news.povray.org>...
>Well, it makes sense that it may happen when the rays have extremely low
>slopes (that is, they go over 1 unit in the X direction for every 100000 or
>so units in the Z direction), but why does it happen with an orthographic
>camera? At only a distance of about 1000 units? Surely POV can handle more
>than four decimals.


The problem is that a torus is a fourth-order polynomial.  So, in order to
get four decimal places of accuracy in a ray-torus intersection, POV-Ray
needs a whole lot more decimal places of accuracy in the intersection code.
I'm not sure about the exact math POV uses, but I would guess that for four
decimal places of accuracy, you'd need variables that can store 16 decimal
places.

--
Mark

Post a reply to this message

On Fri, 26 Oct 2001 20:06:24 -0400, Slime wrote:
> Well, it makes sense that it may happen when the rays have extremely low
> slopes (that is, they go over 1 unit in the X direction for every 100000 or
> so units in the Z direction), but why does it happen with an orthographic
> camera? At only a distance of about 1000 units? Surely POV can handle more
> than four decimals.

surely you realize that the distance of an orthographic camera is meaningless.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message