<p dir="ltr">Hi Jonas,</p>
<p dir="ltr">On Fri, Feb 7, 2014 at 11:36 PM, Jonas Eschenburg &lt;<a href="mailto:indyjo@gmx.de">indyjo@gmx.de</a>&gt; wrote:<br>
&gt; Hi everybody,<br>
&gt;<br>
&gt; Does Cycles keep track of how many samples/bounces/rays it actually had<br>
&gt; to calculate during a render? And if so, is there a way to exactly limit<br>
&gt; the amount of work a render takes?</p>
<p dir="ltr">It doesn&#39;t keep track of this, but if I understand it right then it wouldn&#39;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&#39;t think any path tracer can do this. Even if you know the settings for bounces etc., you can&#39;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.</p>

<p dir="ltr">&gt; Background: Bitwrk, a network rendering project I am working on, would<br>
&gt; profit from predictable render times. The prediction has to be<br>
&gt; independent of CPU speed, so a simple time limit is not suitable.<br>
&gt; Rather, I&#39;d like to impose specific limits on the amount of work a<br>
&gt; certain render task takes.<br>
&gt;<br>
&gt; At the moment, I am limiting work like this (non-branched path sampling):<br>
&gt;<br>
&gt; cost_per_pixel = scene.cycles.max_bounces * scene.cycles.samples<br>
&gt; cost_of_tile = cost_per_pixel * (xmax - xmin + 1) * (ymax - ymin + 1)<br>
&gt; if cost_of_tile &gt; MAX_COST:<br>
&gt; raise RuntimeError(&quot;Cost limit exceeded&quot;)<br>
&gt;<br>
&gt; This is, of course, only a very rough worst-case estimation. Is there<br>
&gt; anything I can do to make it better?</p>
<p dir="ltr">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&#39;t do that then I guess you&#39;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&#39;s still easy for the estimate to be off by a factor of 10 or 100.</p>

<p dir="ltr">For limiting the amount of time a render, we don&#39;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?</p>

<p dir="ltr">Brecht.</p>