I understood that William was just demonstrating
a bug.

However, he made no real attempt to pinpoint
what part of the SDL was at fault.

So far I've eliminated the radiosity feature as
a cause, and I've narrowed it down to some
form of hall of mirrors effect with isosurfaces
and quartics with user defined function pigments.

My guess is that the combination of functional
objects (isosurfaces, and quartics) and
function pigments, is causing errors in the
floating point of a small amount not normally
any problem, but when combined with larger
max_trace_levels and reflections with repeating
checkers, is causing a value "bounce" which
makes adc_bailout not kick in, and hence it
tries to cast all the reflection rays, which consumes
too much memory and then freezes.

My suggestion to the POV team would be to
check for user input (render cancel) if after some
amount of time (10 seconds?) a pixel is still not
rendered. This might result in a perception that
POV handles error conditions better.

As for William, POV is a free program made
for the express reason of creating pretty pictures.
As such, POV is inherently a waste of time.

Additionally, any bug that has easy work-arounds
isn't ever going to be high on anyone's to-do list.

Post a reply to this message