Am 28.04.2010 03:32, schrieb Edouard:

> That's great, but the renders are still really really slow. The overnight one
> was about 7 hours, and the ones with low radiosity settings, but reading the
> cache, look like they will take several hours themselves.
>
> If I turn off the reading of the cache, the renders go very fast (about 2
> minutes) but look pretty bad (which I expected).
>
> Are there some settings in the global_settings { radiosity { ... } }" block that
> would let me have a fast render by mostly using the cached data? Or is the
> amount of data in the cache file from the high quality pass the bottleneck (the
> cache file is about 88MB)?

It's probably the high-quality cached samples that kill your render time.

While /taking/ samples can be a pretty time-consuming process depending 
on the quality setting, /looking up/ samples is not trivial either.

The most important factor there is the "overlap" of samples: A high 
number of re-usable samples for a given point is the worst-case scenario 
when it comes to sample lookup. You can reduce this by using a lower 
nearest_count and/or a higher low_error_factor in the sample-taking 
pass. (Of course both /may/ reduce quality.)

You can also speed up sample lookup of already taken samples by using a 
lower error_bound value in the final pass, but this is less effective 
than increasing low_error_factor during sample-taking, despite having 
the same effect on image quality.

Note that a high number of samples /per se/ is not necessarily fatal to 
lookup speed. Using a very low error_bound in both passes, while 
drastically increasing total sample /count/, will typically not change 
sample /density/ (as it also reduces sample /size/), and therefore 
should only have a rather benign impact on sample lookup speed.

Post a reply to this message