Warp wrote:
> SharkD <nomail@nomail> wrote:
>> A lot of times, the first and last few blocks render much more quickly than the
>> middle blocks if they are composed of mostly empty space.
> 
>   No matter what you try to do, the estimation will always be off.
> However, a simple algorithm like I described is very easy to implement
> and contains basically no overhead whatsoever, and may be more useful
> than nothing.
> 

In fact, if the blocks are rendered in random order (rather than across 
rows like they are now), then area locality would have less of an effect 
on the estimate, making it more accurate.

That is, many times local blocks have correlated render times, while 
blocks that are separated by some distance have unrelated render times 
(much like the Noise3D function that I'm so fond of :) ).  During tough 
patches, the render time will be overestimated.  The corollary is that 
in fast to render areas, the render time will be underestimated.  This 
is compounded by having several slow-to-render or quick-to-render blocks 
in a row.  Randomly picking between the blocks will alleviate this 
(although I don't know what effect it will have on Radiosity).

...Chambers

Post a reply to this message