>>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.

Ah... well the function I want POV-Ray to draw *never* goes negative...

Actually, maybe POV-Ray doesn't like that fact in itself! :-S

> 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.

I was wondering... is there a document anywhere that explains EXACTLY 
how POV-Ray renders isosurfaces?

> 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.

...sounds like a conclusive "NO" then. Shucks.

Andrew @ home.

Post a reply to this message