Summary of below: my reported problems are nothing new to worry about in Beta
32. I'll report back if I find anything.

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> I find this hard to believe, as radiosity code has not changed from
> beta 31 to 32, except for some performance counters that are kept local
> to each thread. Are you sure you're not comparing to an earlier
> version's performance?

OK - will check - my observation is based on having a render running quickly in
Beta 31, then a few minutes later running very slowly after an update to Beta
32.

> (In case your scene should happen to contain only a single, small,
> "radiosity-intensive" detail, such effects might occur when POV is waiting
> for the last cell to complete at the end of each pretrace step.)

Wasn't that; it was throughout the passes (3 radiosity pretrace passes in
total). See my last comment (below).

> As you can see, there is no SMP involved so far. It's just the block-
> oriented pixel rendering order you see, nothing more.

Yes, I see. I understood the 3.6 horizontal artefact, and I'll admit that block
artefacts are perceptually more acceptable.

> A good rule of thumb for pretrace tuning is that at least half the samples
> should be gathered during pretrace already; unless you're using exotic
> settings, this is usually sufficient to keep the artifacts below visibility.
> Provided you switch "always_sample" off, that is.

always_sample had slipped through the net. D'oh! :o)

> Make sure to use "low_error_factor" and "nearest_count" - they're the
> chief weapons to make sure pretrace gives a good sample coverage for the
> main render.

Good advice, which I was 'bending' to make the render fit in memory: I think I'm
making radiosity work too hard, with 'normal on', and using a crackle pattern as
modifier to an implicit surface.

Post a reply to this message