Samuel Benge wrote:

> I understand this. But if we *can* get bevelled edges using higher
> accuracy values, why not let people use it that way? 
> 
Well... it would (again) be some sort of "art produced by numerical 
errors in the solver". 
I certainly won't keep you from doing such things and it's great if 
it works for you. 
However, don't yell at us if things break in the next version. Numerical 
algorithms typically give results which are only exact up to some certain 
error (i.e. accuracy). And it is no good idea to rely on a special behaviour 
of the numerical error. 

>> (3) It does greatly improve the actual surface accuracy. While the current
>>    code will have the real root depth within the specified accuracy, the
>>    patched code will have it within 1/10 to 1/100 (typ.) of the accuracy.
>>    This in turn means, that one can render equally-well images with smaller
>>    accuracy and hece faster. See below, too.
> 
> This is what's really frustrating me.... I know the patch is better when
> it comes to accuracy. With the 'official' isosurface, we have to use
> accuracy values which are MUCH SMALLER than the needed 'grain size', or
> resolution of the isosurface to rid ourselves of the black dots.
> 
The actual accuracy improvement depends on the function used. 
It seems you did not completely understand the grain size argument. 
If you look at the isosurface (mathematically!) of a function, this can be 
very smooth (like a billard ball) strongly grainy (like a sponge). 
In order to get a useful representation of the isosurface, you normally 
need an accuracy value which is smaller than the characteristic grain 
size. This is necessary to make sure that the first root along the 
light ray is actually found (and not any root). This is independent of 
my patch. 


landscape), are very smooth and hence the "grain size" is large and 
you could use a fairly large accuracy value. So, here we find the correct 
(i.e. first) root easily but the result for the ray depth of the root may 
be displaced from the real location by the amount of accuracy. And here 
comes the patch: By linearly interpolating, this guess for the actual 
location of the root between the last two evaluation points can be 
"greatly" improved. 
How much depends on the function used. For very smooth functions 
(especially the mars topo which is itself a linearly interpolated function), 
you can gain the mentiones factor 10 to 100. For other less smooth 
functions it will be less and for really rough ones we won't win anything 
but also not lose anything. 

> Can I give you an example isosurface statement, to test my theory on
> this? I've seen the problems; I believe your patch fixes them. If we
> break even on render time, so be it. A fix is a fix.
> 
Well, feel free to post or send me the SDL code in question. I'll give it a 
run (unless it takes ages :). 

> *Sigh* I wish I knew how to compile POV's source code... :c/
> 
tar xfj povray-3.6.1.tar.bz2
./configure COMPILED_BY=your_name
make

Wolfgang

Post a reply to this message