|
 |
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'

|
 |