I'm trying to understand how I'm screwing this up.  I'm running POV v 3.6 on
WinXP, and I'm confused as to why it crashes when using the code below...

I've marked 3 lines to play with.  If I uncomment any combination of these lines
things work fine EXCEPT if Line #3 is uncommented all alone.  Then, POV throws
an unhandled exception and needs to be reloaded.

Lines #1 and #2 are the essentially the same math as #3, except I've split the
position and the rotation of the sphere up.  Why does it choke on the
combination of the two, but not on the single operations?


#version 3.6;
camera {location 10*y  look_at 0}
light_source {<-30, 30, -30> color rgb <1, 1, 1> }

#declare ii = 0;
#declare X0 = 0;
#declare X1 = 1;

#while (ii <= 360)
   #declare ii = ii + 1;
   #declare X1 = X1 + X0;
   #declare X0 = X1 - X0;

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

#end

Post a reply to this message

How Camp <hac### [at] gmailcom> wrote:
> I'm trying to understand how I'm screwing this up.  I'm running POV v 3.6 on
> WinXP, and I'm confused as to why it crashes when using the code below...

  It doesn't crash here. However, I wonder if the problem might be in
that X0 is getting *huge* values.

-- 
                                                          - Warp

Post a reply to this message

Wasn't it Warp who wrote:
>How Camp <hac### [at] gmailcom> wrote:
>> I'm trying to understand how I'm screwing this up.  I'm running POV v 3.6 on
>> WinXP, and I'm confused as to why it crashes when using the code below...
>
>  It doesn't crash here. However, I wonder if the problem might be in
>that X0 is getting *huge* values.
>

It crashes for me with 3.6 under Windows XP.

I noticed that:

   it doesn't crash if the radius of the spheres is larger.
   the larger the value of the radius, the larger X0 can be

   it doesn't crash if there's a single sphere equal to the last one

   it doesn't crash if automatic bounding is switched off
     which would explain the previous point, because automatic bounding
     is normally switched off for less than three objects

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   It doesn't crash here. However, I wonder if the problem might be in
> that X0 is getting *huge* values.

Heh, I agree that the values are silly.  But I don't understand why those exact
same values are accepted for both Lines #1 and #2, but not #3.  Where exactly
are the large values screwing things up?

Post a reply to this message

Wasn't it How Camp who wrote:
>Warp <war### [at] tagpovrayorg> wrote:
>>   It doesn't crash here. However, I wonder if the problem might be in
>> that X0 is getting *huge* values.
>
>Heh, I agree that the values are silly.  But I don't understand why those exact
>same values are accepted for both Lines #1 and #2, but not #3.  Where exactly
>are the large values screwing things up?

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

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.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

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