Actually, sitting through what may have been THE most boring lecture I
have ever attended... And I have attended quite a few, I came to a     
solution to your problem.  I have yet to implement it except on paper
since I have been extremely busy (though I can now claim the 7th fastest
ergometer score on my crew team since I covered 2000meters in 6:31.2
today after covering the same distance in 2.4 seconds more yesterday and
got perhaps that much sleep between them) So if you will forgive me, I
am going to nap, then go to a meeting, then lift, then do homework for
three classes and then tomorrow after my long day is over, I will
implement the code... The sad part is that it isn't so hard to
implement, but I just haven't sat down and typed it in (btw the radius
will and must be defined by the size of the box used...)  

Steve 
(of course in the time it took me to write this...)

Ken wrote:
> 
> 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