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.

Post a reply to this message

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

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

Wasn't it Andrew C on Mozilla who wrote:
>>>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

If the threshold is zero, then the surface that gets rendered is the set
of points where the value changes from positive to negative. I don't
think that POV can find a zero surface that's positive on both sides.
(If it did find such a surface, how would it know which was the inside?)

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

As far as I know, only the source code.


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> I don't
> think that POV can find a zero surface that's positive on both sides.
> (If it did find such a surface, how would it know which was the inside?)

Well, as long as the threshold is set to something greater than zero, it can
find the surface. The "inside" is the set of points whose value is less than
the threshold.

In any case, the technique of taking the square root when the threshold is
zero is obviously flawed because that makes the function undefined in the
negative region, as has been pointed out.

There are other functions, such as atan (as long as it returns a value
from -pi to +pi) which have a similar effect yet are defined everywhere.
However, this won't help. Although it may be possible to use a lower max
gradient with this technique, the function is now much closer to zero
everywhere. This means that POV-Ray can't say "the value here is 500 and
max_gradient is 5 so i can go 100 units and be sure I won't hit the
surface"; rather, it will say "the value here is 5 and the max gradient is 5
so I can only safely go 5 units." So I doubt it will speed things up.

The only real way to speed up the isosurface render is to try to make your
max_gradient as uniform as possible. If the majority of your function has a
max gradient of 1, and one part of it has a gradient of 1000, then you'll
have to set the max_gradient to 1000 which makes the evaluation really slow.
If you can fix that area so that the max gradient is 1 everywhere, then you
can set the max_gradient to 1 and get a good render speed.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message