>> (I read somewhere that dividing your function by a big number makes 
>> max_gradient lower, but doesn't make it trace any faster. But this trick 
>> makes the big numbers small, but leaves the small numbers alone so 
>> POV-Ray doesn't go around taking tiny steps there any more.)
> 
> That sounds like me
> 
> http://www.econym.demon.co.uk/isotut/dont.htm

Yeah.

Ooo... "you can't use arrays in an isosurface function". Um... well... I 
just did. :-.

> I'll have to go back to that page and see if your trick can be applied
> generally.

You gotta see the isosurface function the way POV-Ray sees it. (See the 
graph I posted in another reply here.)

I've been thinking about the way POV-Ray's sphere-tracing algorithm 
works. (I should diagram that thing sometime...) Anyway, it seems that a 
large max_gradient isn't too much of a problem, by itself. The problem 
occurrs when

1. The function has a high max_gradient.
2. The function has large areas of "nearly zero".

The high max_gradient makes POV-Ray take tiny little steps through the 
nearly-zero areas. (But if you turn down the max_gradient, the high 
values make POV-Ray take giant steps and completely miss the surface.)

The logarithm function is perfect here, because it makes big values 
small, but doesn't change small values much. (The sqrt() function would 
work too, but to a lesser extent.)

Problem #1 is going to be negative numbers. You'll have to bias the 
function completely into positive space before attempting to take the 
logarithm, and then bias the result back. This fails for functions that 
zip of to minus infinity. (Actually, it's probably best to keep the 
whole function above 1, rather than just above 0.)

Note that my solution works because the surface I'm actually trying to 
draw is quite simple, it's just the maths is confusing POV-Ray. Not sure 
what happens if the surface really *is* complicated - I suspect you 
can't do too much about that...

Post a reply to this message