> AIUI, the isosurface stuff works by assuming that the function's value
> won't change by more than x/max_gradient over a distance of x, so it uses
> this and an algorithm sorta like newton's method or the sturmian root
> solver to find points that lie on the surface.

[Actually it's x TIMES max_gradient, but you've got the idea.]

POV-Ray samples the function more densely when it gets "close" to a 
zero, and less densely when it's nowhere near one. To know what "near" 
is, it must know the maximum gradient. It doesn't actually need to know 
multiple derrivates or anything, it just needs an upper bound on how 
densely it needs to sample to not miss any zeros.

> This all gets ugly if the
> function, like, has an order greater than 1, or has an exponential or 1/x
> in it, etc, since these functions have derivatives that increase
> indefinitely in certain regions.

More specifically, it gets ugly if the function contains discontinuities 
or poles. Beyond that, it works for arbitrary functions. (Which is why 
POV-Ray uses it. Other methods work only for polynomials or only for a 
function you have the derivative of, etc. But this method works for 
*anything*, provided it has "nice" numerical properties.)

> For example,
> 
> x^2 = 10
> 
> Its derivative is x which increases indefinitely

True - but POV-Ray only ever renders A FINITE SECTION of the function. 
;-) Within that section, the derivative will be bounded.

This doesn't alter the fact that the derivative could well be 
increasibly big, causing POV-Ray to take drastically more samples than 
is really necessary near the zeros (where the derivative is actually 
much smaller).

> but if we go
> 
> x = sqrt(10)
> 
> Then we end up with a function whose derivative is bounded and whose 0
> locus (sorry if I'm not using correct terminology here) is still the same.

Correct. The surface to be rendered hasn't changed, but the derivative 
doesn't vary so wildly any more. (In fact, in this trivial case it's 
constant.)

> This is what Orchid effecitively did with his exponential function.  By
> taking the log of the whole function he created a new function with the
> same properties.

My particular function was something like x^18 + ... = 0. It has almost 
vertical sides, yet the "interesting" part has a tiny derivative. My 
using the log() function I can "magnify" the interesting bit, and zoom 
out the unimportant vertical walls that are confusing the poor root solver.

However, note that you must make sure the function is NEVER NEGATIVE, 
since log(-1) is a complex number, and POV-Ray won't like that. This 
sometimes requires you to translate the function in the Y-direction, 
take the log, and then translate the result back again:

   f2(x) = k + log(f1(x) - k)

Selecting the correct k turns out to be very critical. The log function 
shrinks large features, but it can also "magnify" small ones. If you get 
the "wrong" value for k, you can end up creating big vertical side RIGHT 
NEXT TO THE ZEROS. That means you MUST use a high max_gradiant or 
POV-Ray will overshoot the zeros - the exact thing we were trying to 
avoid...

(The problem gets even more fun if you start taking double-logs!)

> I'm curious, could this kind of thing theoretically be done automatically
> by povray?  What if it were to use log(function) or sqrt(function) or
> 1/function to find the surface points rather than the actual function, and
> the max_gradient were to apply to that function instead of the original?

For every function for which this is faster, there is another one for 
which it is slower. It would probably take more time to detect which 
case applies than to just use the "wrong" variant. (See above.)

OTOH, it might be worth making a *keyword* to do this kind of 
optimisation automatically instead of altering the function by hand...

Post a reply to this message