Jim McElhiney wrote:
> 
> [...]
> 
> The effect of the bug that I would expect is as follows:  many samples
> are getting stored in the ot_ tree at too small a node size, so are not
> getting found when you need them.  Therefore, they aren't getting
> included in the averages, except when your sample point is very
> close to them.  Whether or not they are included is
> dependent on which side of the caching tree node's boundary you
> are on, so the old sample drops out of the contribution suddenly between
> two pixels while its weight is significant, causing discontinuities.  You would
> 
> expect these discontinuities in lighting to align with the scene axes, and
> to be more pronounced at low nearest_count values, and high
> values of low_error_factor.
> 
> The quick hack just forces everything to be stored in a bigger node,
> so more nodes are looked at when looking for things to average in.
> This does take a little more time, since the tree is traversed a lot.
> But, I'm kind of surprised that the speed got that much slower.
> Probably a small part of it is the tree traversal per se, and a larger
> part of it is the execution of the function (ra_avearge_near) which calculates
> the weight and averages it in.

Yes, this sounds logical.  The stats also say the render with your
modification - while taking much longer - took much less radiosity
samples.  The factor of 4 i used as you suggested could have been simply
too much.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message