Hey, everyone!
I just remembered something which I've remembered before but forgot because I remembered something else. But now I remember it quite well and so I'm writing this. In the near future, I'll probably remember that I wrote something about remembering.
Oookay! So, quick question: In Blender, would it be plausible and possible to show users 'how much more time' is remaining in the renders, instead of the 'elapsed time'? I know it is possible, but the difficulty of implementing such a feature is beyond my knowledge. This way, after changing some settings and the like and hitting the render button/shortcut, we'll immediately then be informed (even after BVH caching and what not) how long the scene will take to finish rendering. Then once we see that it is beyond our timeframe/schedule/deadline, we cancel the render, do some tweaking, settings adjustment, and render optimization, then do a render again.
What do you think?
-Reyn
12 comments:
This definitely sounds possible; I custom-compile Blender, and I could try to get something like this working. I think that BI and Cycles would each need a different implementation, though (as for every other render engine).
Coool! yeah I think that would be great to have and I like your idea that by knowing the remaining time we can easily just cancel the render and tweak the settings...
I can't speak for both rendering engines (BI and Cycles) but I noticed with Cycles, not all tiles render at the same amount of time so it might not be possible to get the actual render time - I could be (and I hope I am) wrong though. With Progressive Refine enabled, it might be possible since each sample renders at a more constant rate (I think).
There is a python script that does exactly this but I think it only gives approximate time. I personally haven't tried it yet (since mabagal naman yung renders ko and I have a lot of spare time so I just calculate the render time manually hehehe)
Here's the link to the Python script (https://github.com/le717/Cycles-Render-Time-Calculator)
Forest Ka: I'd love to see and test what you can come up with. Bump me whenever you could.
John Imperio: Thanks for sharing your thoughts! Useful link as well. Kudos, kabayan!
-Reyn
It is not possible to have an exact "Remaining time" value.
Imagine, you have a very difficult object and shaders in the centre of the image, therefore it looks like render time will be long, but when Cycles comes to the outer edges, there is only Sky and therefore renders very fast.
Same if it starts easy in the centre, but gets more complicated outside.
There is already such a thing! I think only for animations... not sure. http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/Render_Time_Estimation
DingTo:
Yes, you are very correct on the tiling and varying approximations. However, what if there's a cache system for determining the factors that affect a certain tile (e.g. transmissions, transparencies, shadows, etc.) then propagating over to the rest of the tiles (depending, of course, on the number of tiles set to x and y, accordingly); the cache then averages the total with an accurate mathematical representation of the data. Something like what the BVH caching does, but instead of caching bounding volume hierarchies that would generally relate to geometries and what not, this render calculator caches light data (beams, bounces, dispersions, etc.).
For example, we have an image render with four (4) tiles total, situated like a grid, upper left being the first tile, upper right the second one, lower left the third tile, and fourth as the lower right. The first tile has nothing but a plain diffuse wall, the second tile has heavy glass surfaces, the third tile has volumes, and the fourth tile has reflections from the scene. We are pretty much sure (with the current state of the renderer), that these tiles would be rendered at different lengths of time; what the calculator does then is it takes each of the tiles separately, analyzes them accordingly (with an effective algorithm), and using another algorithm, it computes for the total time the four tiles would take to render (if ever there's a reason a simple averaging would not be possible). Of course, it wouldn't make sense if the calculator computes the render time in the same way that it already would as though the scene has been rendered. Say, we already know that Scene X takes one (1) hour to render and the calculator already knows that too; but when we already do the actual render, it takes a total of two (2) hours because it determined the render calculation based on the virtual finished render that has been done, which isn't really optimal. ;) If the calculator would be able to utilize both the CPU and GPU's computing capabilities to speed up the algorithm, that'd be a blast. :)
I'm really thinking wild and most likely improbable here, Thomas, but I really believe there's a way for this.
Thanks! :D
-Reyn
Greg:
I believe that is not the answer, though it's close.
It did mention in the page that
"Note that an accurate estimate requires at least the first frame of the animation to be rendered."
That is what we're trying to avoid, so we could early on optimize the scene however we want to without wasting so much time on the first or few renders (of course, it does help to be knowledgeable on the render optimization tricks as well ;) ).
My proposal is, before even doing the actual render or prior to rendering the first tile, we'd have options like:
- an option to click a button/input fields therefore outputting the render time our scene will take
- just as BVH caching works prior to rendering, the renderer will then list down the remaining render time and it ticks everytime, getting lower and lower until it comes to 00:00:00
Thanks for sharing, Greg. I really appreciate it. ^_^
-Reyn
I'd have thought that rendering at a very low (say 200x200) resolution would get you close to a firm (ish) view on the distribution of render time across the scene and be fast enough that you wouldn't be waiting long for it, then that distribution could give you fairly close approximations of render times once you'd done a tile or two at your target resolution.
I might well be wrong but it seems reasonable that the linearity (or not) of render time by resolution ought to be predictable, such that you only need to do an analysis render at low res (but at final sample count) to know how long it should take at final res.
I could of course be talking out of my... hat.
There is no way to reliably predict or calculate render times. You seem to forget that you're not only working with software, there is the hardware side to it as well. If you can create an algorithm that can accurately take into account the multitude of variables such as the processor temperature at the time and other hardware component factors that affect computing speeds, You're out of luck. What popular softwares do nowadays is only sampling. Once you pick your settings the app tries to run a small simulation, and then multiplies and approximates the time needed to render the whole thing. That's fine and all but what's the use of getting an estimate which is waaaaay off base(Usually in hours...).I mean... you'd have better luck asking a fortune teller...;)
There is no way to reliably predict or calculate render times. You seem to forget that you're not only working with software, there is the hardware side to it as well. If you can create an algorithm that can accurately take into account the multitude of variables such as the processor temperature at the time and other hardware component factors that affect computing speeds, You're out of luck. What popular softwares do nowadays is only sampling. Once you pick your settings the app tries to run a small simulation, and then multiplies and approximates the time needed to render the whole thing. That's fine and all but what's the use of getting an estimate which is waaaaay off base(Usually in hours...).I mean... you'd have better luck asking a fortune teller...;)
A little late to the party, but for my 2c:
I didn't think accuracy would actually be very feasible considering variations in speed for each tile, but I'd be happy with a rough guesstimate.
...though I guess at that point it'd probably be easier and quicker to just pull out a calculator and do the guesstimate myself based on elapsed time and number of tiles rendered ;)
A little late to the party, but for my 2c:
I didn't think accuracy would actually be very feasible considering variations in speed for each tile, but I'd be happy with a rough guesstimate.
...though I guess at that point it'd probably be easier and quicker to just pull out a calculator and do the guesstimate myself based on elapsed time and number of tiles rendered ;)
Post a Comment