Mike Williams <nos### [at] econymdemoncouk> wrote:

> It's clearly in the processing of the automatic bounding slabs.

You're right, of course.  I see that if I turn off automatic bounding altogether
(-UB) then I cannot produce an error, regardless of what I choose for a radius.

I can do this, though:

#declare Y0 = vrotate(<sqrt(X0),0,0>, ii*y);
sphere{Y0, 1E-0 pigment{rgb 1}} // Line #3

Rather than:

sphere{<sqrt(X0),0,0>, 1E-0 pigment{rgb 1} rotate ii*y} // Line #3


The former doesn't crash (while the latter does).  I suppose I assumed that
vrotate() would be the same math as the rotate keyword.  Does that mean
calculating sqrt() + rotate 'on-the-fly' yields larger rounding errors than
using the vrotate function?  The bounding box calculations should be the same
in either event, shouldn't they?  (Clearly, they're not.)


> Perhaps rounding errors are causing some of the bounding slabs to have
> negative volume. If the rotation calculations are accurate to 1 part in
> 10^26 then that error could be larger than 0.1, the radius of the
> sphere. I tried to check out this theory by looking at max_extents and
> min_extents, but they seem to only return 6 digit accuracy, so the
> interesting spheres all appear have volume zero.


So... it seems POV doesn't check for negative bounding volumes.  I've never
looked at the source code, but maybe it's an easy fix.  :)

Thanks for your patience in helping me understand.

- How

Post a reply to this message