|
|
So, while fiddling with trace() and objects declared into
arrays, I've noticed the following: when outputting the
specular value (asked that in a recent thread), I get,
when using str(Value,1,20) this:
1.#QNAN000000000000000
Now, I expect NAN is Not A Number. I'm not too
sure how this can happen... I'll look some more into it,
but perhaps some information on NAN and possible
origins (dividing by something near 0 or multiplying with
something too large) might aid me in looking for the actual
error (which might be in my code, can't tell for sure yet).
Nontheless, shouldn't POV have some means of avoiding
that?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde
Post a reply to this message
|
|
|
|
So, fiddling with the code came up with this:
I can't really find where the error is placed. I'll
try to cut down the source-code to the bare
minimum which'll reproduce the error with
#QNAN . I've tried using the same pretty close
numbers in the calculation where this error
is returned. In the scene, it uses 0.47... with
pow(0.47.... , 1/.03).
Works fine outside of scene, but not inside of
it.
Only thing I noticed is that when commenting out
an array declaration (trying to fill it with UV-Vectors),
the error is gone.
So, if I do:
#declare Array=array[2] { <1,.03>,<.9,.02> }
everything is working, but with
#declare Array=array[2]
#declare Array[0]=<1,.03>;
#declare Array[1]=<.9,.02>;
the error pops up.
Anyways, I'll post the code once its stripped. If anyone
has got any suggestions what to look for, I'd be happy
to attempt that.
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde
> So, while fiddling with trace() and objects declared into
> arrays, I've noticed the following: when outputting the
> specular value (asked that in a recent thread), I get,
> when using str(Value,1,20) this:
>
> 1.#QNAN000000000000000
>
> Now, I expect NAN is Not A Number. I'm not too
> sure how this can happen... I'll look some more into it,
> but perhaps some information on NAN and possible
> origins (dividing by something near 0 or multiplying with
> something too large) might aid me in looking for the actual
> error (which might be in my code, can't tell for sure yet).
>
> Nontheless, shouldn't POV have some means of avoiding
> that?
>
> --
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
> Email: Tim### [at] gmxde
>
>
Post a reply to this message
|
|