POV-Ray : Newsgroups : povray.advanced-users : Isosurface speed : Re: Ooo... a solution? Server Time
6 Oct 2024 15:20:07 EDT (-0400)
  Re: Ooo... a solution?  
From: Michael (Micksa) Slade
Date: 28 Sep 2006 09:19:51
Message: <pan.2006.09.28.13.20.12.48220@knobbits.org>
On Wed, 27 Sep 2006 20:44:05 +0100, Orchid XP v3 wrote:

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

Yeah, the magnification of small values (which also applies to, say,
sqrt(x)), is something I forgot about.  I guess real world functions would
be less trivial to "map" in the sense I was talking about.

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

Why would you want to do that for a function other than a
double-exponential?  Masochism? Maths fetish? :)

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

Also, I just realised, I think most functions with ever-increasing
gradients could be reined in by putting it in a min() or max() function,
or both.  Would that work with your exp function?

Mick.

-- 
Remove the -news from my email address.
http://mickworld.knobbits.org/


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.