Stephen Lavedas wrote:
> 
> Okay Ken... you have a couple of magic numbers in here (a magic number
> is a number that is just there for some reason and no logical
> explaination is known except by the author)  The most important one is
> 1.6*pi/90-bb where did you get this figure?  I am trying to figure it
> out, and my guess is that you just kept tweaking it until there weren't
> any gaps...Also, where did you come up with the origial scale for the
> box?
> 
> Steve

  I have finally figured out why it was necessary to add the extra .1 to
the object size. As the boxes are rotated and scaled the are rapidly
reduced in size for the y dimension. In fact the are reduced to zero
on the last loop of the counter. When the loop hits the last count
the object has reached a dimension where it is divisible by itself
and Pov notes a divide by zero error.
 The Pov team, in their own infinite wisdom, have built a trap into
the program to protect us from this kind of situation. Unfortunately
when Pov steps in to correct the error it automatically assigns a
scale of one to the offending object. I could not for the life of
me figure out why my dome was so distorted on the top most row.
I finally, probably by accident, found that adding the .1 value
kept the object within scalable limits before the count died and Pov
would be forced to rescue me from myself.

I wonder If I could save myself a lot of trouble by starting the first
rotation from the top of the dome downward opposite it's current
behavior. This way it would never reach zero because the object size
will be increasing instead of decreasing through the loop.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message