"TomAust" <aus### [at] aust-manufakturde> wrote:
> > the rendertime was 23min with Beta29/30
> > and 220min with Beta30rad1.
> >
>
> Just finished the comparing renderings with same settings but in lower
> resolution at W1500xH1000.
> And now the rendertimes are
> 6min 35sec with beta29/30
> and just
> 16min 49sec with beta30rad1 !
>
> Perhaps a helpful note ?

It is at least *some* hint on what might be going on.

It is very strange however why a 9-fold number of pixels to calculate should
result in a 12-fold effort. Reason says that in the 9-fold number of pixels
shot and with the pretrace resolution defined relative to the total resolution,
we should expect to have about 9-fold the number of rays to trace, 9-fold the
number of radiosity lookups to do, and at most 9-fold the number of radiosity
samples to collect (in fact we should expect less increase, as some areas
should have sufficient coverage at the 1500x1000 resolution already). So that
should be at most 9-fold the rendering time. Well, plus a little bit of
additional overhead as various data structures grow. They're designed to have
sublinear access times though.

Did you keep any stats output?


In any case, this smells like severe performance issues with some data structure
that grows to larger size in the 4500x3000 shot.

Looking up radiosity cache data? No dramatic changes there. Fixed the level at
which a sample is "hooked in", potentially resulting in about 4-fold the number
of samples per node, but that just brought samples per node back to the order of
magnitude seen in 3.6.1.

Creating new sample data blocks? Hm... made a bit of a change there regarding
the locking; I'd actually expect that to speed things up instead, but I better
check.

Creating new nodes in the sample tree? Made significant changes there to change
the locking strategy as well; maybe I messed up something there.

Post a reply to this message