Is there a before you render - time calculator?

[clubber2k]

I already side tracked to this issue on another topic.

I would like to widen my audience

 

I'm not sure why, but the render time estimate (VRAY) isn't steady. time changes up to 50% during render and the counter even freezes occasionally.

 

my current image started as 1hr and 50 minutes after a while it started going up to 4+ hours.

that's time I currently don't have, If I knew that, I would have let it start - but now, I don't want to waste all the time gone ... ahhh....

anyway now its slowly dropping back to 2+ hours.. make up your mind

I wounder if it finished at 1.50

 

ANYWAYS

I wounder if there's some power-full, before you render - time calculator that gives you an accurate estimate, which will quickly simulate all the passes+render and give you a rough but better estimate on how long your render will take at the current settings?

this sound like a time saver. searched google.. found nothing..

maybe it was my key-terms?

 

Thanks

Yuval.

[KIT]

Short answer: nop

 

Long answer: rendering an image is such a complex task that creating a really accurate calculator would be treamendously complicated if not impossible. The one in Vray works by "guesstimation", which is why it behaves like a drunken hypochondriac.

Mostly you start to get an idea for render times as you get more experience, so eventually you'll relay more on your "inner clock" than whatever MAX tells you.

[clubber2k]

Umm..

 

Well that's disappointing. and I'm sure its impossible to be accurate

 

but I can't belive that something close to it, does not exist..

I though of something like a plug-in or script that simulates 5-10% of random buckets of all passes and the render.

at the end it prints a time report for each and a total..

 

this of course will take its time. but if buckets are random this is as accurate as its going to get. and you'll know what your getting into, before you do.

 

anyone wants to pick up that ball?

[Crazy Homeless Guy]

This might help...

 

If your rendering at all your final settings takes 10 minutes to render at 1000x800 pixels, then it will roughly take 40-45 minutes to render at 4000x2400 pixels. 4 times the number of pixels will take 4 times as long.

 

I know it sounds obvious, but just thought I would add it, because sometimes that simple bit of logic is overlooked. I also added extra 5 since presumably the system will be using more RAM, which could slow things down a bit overall.

[KIT]

And still it's very approximative. For one, modern rendering engines use a lot of adaptive and random algorithms (and sometimes even adaptive randomness ). So for instance, changing the size of the render could have the Anti Aliasing sampler catch details that where previously being overlooked (or vice versa) having significant impact on the render time that goes beyond what you would expect. And the same can be said for GI sampling, area shadows,etc etc.

[erickdt]

I use a similar system to what Travis describes except a slightly different calculation:

 

If your render time for your low resolution test rendering @ 1000 pixel across is 4 minutes you can multiply that rendering time by 4 for your 2000 pixel across rendering (16 minutes).

 

Why 4 times instead of 2? Because if overall resolution is doubled you're making 1 pixel into 4 pixels not 1 into 2. IOW: The pixels quadruple for every doubling of resolution.

 

I've found this to be a generally very accurate system for calculating render times.

[SandmanNinja]

What erickdt said. I loves maths...

[Ricardo Eloy]

Just another bit:some renderers show you an estimative. VRay can do that, though not really accurate. I guess good old math is still the way to go.

[Crazy Homeless Guy]

Maybe this doesn't apply to all, but our farms has machines with different numbers of cores. Like stated above, this calculation seams to be fairly linear also. If a rendering takes 1 hour on a 8 core machine, it will take roughly 4 hours on a dual core machine.

 

But again, this is just a rough estimate, don't bet the farm on it.

[Justin Hunt]

most if not all the rendertime calculators, use the assumption of , If this bucket is taking this long then so will the rest. therefore if a bucket is on a really complex part of the model the render time will be really long and on simple parts really short. Hence the constant changing numbers.

 

Backburner does the same, except uses the last frame rendered.

 

Its not impossible to calculate how long something will take, just time consuming. So by the time you it has calculated how long it will take to render, you may as well have rendered the image in the first place.

 

jhv

[clubber2k]

most if not all the rendertime calculators, use the assumption of , If this bucket is taking this long then so will the rest. therefore if a bucket is on a really complex part of the model the render time will be really long and on simple parts really short. Hence the constant changing numbers.

 

Backburner does the same, except uses the last frame rendered.

 

Its not impossible to calculate how long something will take, just time consuming. So by the time you it has calculated how long it will take to render, you may as well have rendered the image in the first place.

 

jhv

 

 

thats what I thought.

I did some readying and looking and found that there is no a way to force vray to go through random buckets at only 10% render. that is in fact all you need to get a good estimate. some buckets are fast, some are slow and only after going through most of them you get a good estimate.

going through random 10% could give the same resualt.

 

maybe thats something they can work on the next build.

 

Homless, I think the multilayer changes dramatcly with each system:D when going into higher details sometimes more object detail is calculate no?

[Ricardo Eloy]

thats what I thought.

I did some readying and looking and found that there is no a way to force vray to go through random buckets at only 10% render.

Maybe you could do that using VRay Frame Buffer's "track mouse while rendering" option to point the buckets you think are representative of everything you have in your rendering and then calculate your estimative. Not very practical, but possible.

One thing that crossed my mind is that depending on the method used to calculate/render the image, you can indeed have a good idea of how long it's going to take. If you use, for example, VRay's PPT (or Maxwel's progressive rendering, for that matter), it really doesn't matter which part of the image is being done at the time, because the image is being calculated as a whole, progressively throwing rays at it. Of course, this is the slowest method available, but in theory, can be done.