awsome, thanks!

and sorry for posting it in the wrong place... chris young suggested it :-)
this leads me to a question: Why does it not detect the NAN and drop out of
the parse???

dan

/me likes the way old dos ver works...

Chris Huff wrote:

> In article <3A6231FA.FD3761DD@sunshine.net>, dan williams
> <dan### [at] sunshinenet> wrote:
>
> > I have here a verry interesting little (only happens with particular
> > values) bug, it turned up when I started using linux for povray, the
> > comments in the file say about everything else I know about it.
> >
> > I'd do some debugging if I knew where to start.
> >
> > if you see the sphere you are not affected by the problem, if not, you
> > are.
>
> This group, povray.unix, is for Unix-specific problems. For help with
> the scene language or a possible bug with the core program, you should
> post to one of the general POV-Ray groups, like povray.newusers,
> povray.advanced-users, or povray.general. I'm forwarding this thread to
> povray.general.
>
> If you put:
> #debug concat("rotate < ", str(rbshx, 1, 1), ", ", str(rbshy, 1, 1), ",
> ", str(rbshz, 1, 1), ">")
> in your scene, you will see that "rgshx" is NaN (Not a Number). The NaN
> gets into the matrix and fouls things up. If you put;
> #debug concat("acos(", str((len/2)/0.78, 1, 1), ")\n")
> you will see that you are attempting to calculate the arc-sine of 1,
> which seems to be undefined.
>
> Using a macro to detect and work around this case works:
> #macro ACos(V) #if(V < 1) acos(V) #else (0) #end #end
>
> #declare rbshx = degrees(ACos((len/2)/0.78));
>
> As I recall, the behavior of the inverse trig functions was one of the
> things that was changed in 3.1...they are more mathematically correct,
> but maybe less useable...
>
> --
> Christopher James Huff
> Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
>
> <><

Post a reply to this message