My Specs:
Win2000, Athlon XP2400+, 786MB DDR

So, here goes minimum code:

 #local _Light=-0.47443615353120855;
// <- Replace latest 7 with 69 or with 71 to see change
 #local _Pow=1/0.49999999999999997227;
#local C_Spec=pow( _Light, _Pow );
 #debug concat(str(abs(C_Spec),1,20),"\n")


Just paste it into an empty scene file and render.
 As mentioned in comment above, when exchanging the
latest 7 with a slightly smaller value like 69, it'll give
a proper result, as does 71. The value above will yield
1.#QNAN00000000 for the debug stream.

The actual impact it had on my scene was that all calculation
involving trace() onto a superellipsoid wouldn't calculate
properly, even though trace() worked fine (was able to
place cones with it). Anyways, I guess the error doesn't
have to do with trace() at all, but, as did vnormalize(<0,0,0>)
before final POV-Ray 3.5, the error has some sideeffects
which disrupt some internal algorithms. Note though that
thats my personal guess.
The strange thing though is that the above error doesn't
occur at all times with low values, which is why I tested
69 and 71. Some smaller values work, while others don't.
Haven't gone to larger values for testing, as I'm not sure
what to test for. The above example shows the unpredictability
good enough IMHO. Since it's stripped down to the minimum
possible, should be a good start for tracking the problem (but
again, I'm no expert on that).

Hope this is enough information for the POV-Team to figure
what to do. If anyone else has an idea how I could circumvent
the problem so that my script runs properly, I'd be happy
to hear about it! :-)

Oh, and some confirmations for different systems are considered
appropriate.

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message