Wasn't it Andrew C on Mozilla who wrote:
>It is known that increasing the max_gradiant makes an isosurface go 
>slower. It is also known that if you just divide the result of the 
>function you're drawing, it lowers the max_gradiant, but it won't render 
>any faster.
>
>I was wondering... if I (say) take the square root, that makes the high 
>values less high, while leaving zero unchanged. (I'm assuming 
>threshold=0 here.) Would that make the thing go any faster? Would the 
>increase in speed overcome the extra computation needed for the sqrt() call?
>
>Andrew @ home.

In the general case, strange things happen when you sqrt() an isosurface
function that has threshold=0. That's because POV doesn't like the
sqrt() of negative numbers.

As the POV solver goes looking for a point where a ray intersects an
isosurface, it traps the point in an interval where the function
evaluates positive on one side and negative on the other, and
recursively narrows the interval until it has located the point with the
required accuracy.

If you sqrt() the function, then the POV solver finds itself with an
interval where the value is positive on one side and sqrt(negative) on
the other, which it doesn't like. What tends to happen is that POV knows
when there's a point in the interval, but it fails to find it and paints
the corresponding pixel black.



When the threshold is non-zero, you can write

isosurface { 
  function {  sqrt(F(x,y,z))  -  sqrt(Threshold)  }
  threshold 0

(Note that this is not the same as writing
  function { sqrt( F(x,y,z)-Threshold) }
which produces a black object, as described above.)


I tried some timing experiments. When the max_gradient was changed
appropriately the renderings took exactly the same amount of time.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message