[Bf-cycles] Measuring render work

[Jonas Eschenburg]

Am 08.02.14 22:54, schrieb Brecht Van Lommel:
> > 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.
>
So I understand that even if Cycles did count the number of rays and 
bounces, render times depend on a lot of other factors like geometric 
and shader complexity.

I think that's okay, for me. For a start, it would suffice to have a 
simple cost metric. I will investigate into Cycles source code for that 
(even registered on developer.blender.org!).

I just need a way for a rendering server to tell the client "I stopped 
working after N rays, your scene is much too complex for what you paid 
for". That is much better than saying "I stopped because it took too 
long", which is obviously  hardware-dependant. I can then go on with 
limiting other cost factors, such as shader complexity.
>
> 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.
>
Good idea! Would be a good ways for clients to estimate the amount of 
work they can put into one task. Basically, they want to stuff as much 
work into a task as possible.
>
> 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?
>
Bailing out after some time limit is easy and I do it already. Bailing 
out after some specific number of bounces/intersection tests/whatever is 
what I would like to achieve.

Thanks!

Jonas