On 3/11/23 23:47, William F Pokorny wrote:
> It's not the easiest shape for the solvers.

Ah, and you are using an orthographic camera. This often the worst case 
ray set up for the solvers. Other shapes like the sphere_sweep have 
similar issues with the orthographic camera. Your' also positioning well 
away it looks too.

If I step an ortho camera back just -2 in z and code as the lemon:

#declare r = 1;
#declare R = 0.6;
#declare Y = sqrt ( r*r - R*R );
lemon {
   <0, -Y, 0>, 0, <0, Y, 0>, 0, r
   texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
   sturm
   translate <-.1,0,-.1>
}

I get the attached image.

The ray length matters in that the longer it travels the more the 
accuracy of the ray->surface equation degrades in accuracy. The equation 
has to represent all those useless potential landing steps on the way to 
the shapes surface and this burns up the floating point accuracy.

That bit was my painful discovery discussed in the previously referenced 
github issue. I have a solution for best possible floating point 
hardware accuracy, but the implementation is not trivial...

Bill P.

Post a reply to this message

Attachments:
Download 'behmm.png' (29 KB)

Preview of image 'behmm.png'