[Bf-cycles] Measuring render work

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Feb 8 22:54:58 CET 2014

Hi Jonas,

On Fri, Feb 7, 2014 at 11:36 PM, Jonas Eschenburg <indyjo at gmx.de> wrote:
> Hi everybody,
> Does Cycles keep track of how many samples/bounces/rays it actually had
> to calculate during a render? And if so, is there a way to exactly limit
> the amount of work a render takes?

It doesn't keep track of this, but if I understand it right then it
wouldn't help much. Basically there is no good calculation that you can do
to estimate the render time before actually rendering the scene, I don't
think any path tracer can do this. Even if you know the settings for
bounces etc., you can't know how many times it will actually bounce, which
pixels will be covered by geometry or which will be empty. Even if you did
know, the time it takes to trace a ray or execute a shader is unpredictable
and depends on the scene or shader setup in a way that is difficult to
analyze. Just one tiny setting in a shader can make a big difference.

> Background: Bitwrk, a network rendering project I am working on, would
> profit from predictable render times. The prediction has to be
> independent of CPU speed, so a simple time limit is not suitable.
> Rather, I'd like to impose specific limits on the amount of work a
> certain render task takes.
> At the moment, I am limiting work like this (non-branched path sampling):
> cost_per_pixel = scene.cycles.max_bounces * scene.cycles.samples
> cost_of_tile = cost_per_pixel * (xmax - xmin + 1) * (ymax - ymin + 1)
> if cost_of_tile > MAX_COST:
> raise RuntimeError("Cost limit exceeded")
> This is, of course, only a very rough worst-case estimation. Is there
> anything I can do to make it better?

I think that the most reliable thing you can do is estimate the render time
by rendering a low resolution image with 1 sample, and then from that
estimating the full render time by taking into account the number of (AA)
samples and the full resolution. If you can't do that then I guess you'd
have to do some simple calculation like this, maybe taking into account the
.blend file size to compensate for simple/complex scenes, but it's still
easy for the estimate to be off by a factor of 10 or 100.

For limiting the amount of time a render, we don't really have any builtin
support for that at the moment. You could do a progressive render (where it
render 1 sample for the entire image each step) and then cancel it when the
time runs out?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20140208/f4ddde7e/attachment.htm 

More information about the Bf-cycles mailing list