Render times

[dann_stubbs]

Is there a way to make cinema show the estimated render time, like other apps do?
All I can see is elapsed time, not estimated time remaining.

This is a relatively important thing.
If you can't see the time remaining, then it just goes on and on and the only way to gauge it is by how it appears.
If you know the time remaining, you can either accept it, or make changes to reduce it.

actually estimated render time is a crock and not worth the pixels they are printed with in my opinion

essentially get a calculator and render an "average" frame (that being the issue) and time it by how many frames you have left.

estimated render time will fluctuate hundreds of times so you are better off being involved and if you are looking at a big render do a few of the frames that "you" know are the long ones (the computer does not make any assessments like that - only a human really can at this point) then take those frames add them together then divide by how many frames and again times by the number of frames.

if you had a 1000 frame animation of 1000 glass balls on the first 100 frames that suddenly disappeared into just one solid flat grey box - your render time would be thousands of hours and then after those first hundred frames would suddenly "adjust" down into minutes to go for the last 900 frames (as it averaged the new simple seconds per frame render time of the flat grey box)

and likewise you could have 900 frames of the flat grey box first and your estimated time would be just minutes UNTIL it hit the frame 901 of the thousand glass balls and then your nice short time is blow out of the water as it jumps up to hundreds of hours...

so just rely on yourself and use a calculator - trust me i have a render farm and have been averaging thousands of renders for the past 6 years - currently a human is the best at it

dann

[Dtox]

Well this is sort of the problem with this.
I realize that estimated render times are only a "ball park" figure, if that.

I can't estimate per-frame, because I'm not doing animations, only stills.
So I can only guess based on how long it takes each renderline to advance.

All I would want it for is to know if it's even feasible to continue with the render, or if I need to make adjustments that will give me render times that are even remotely acceptable.
Because I've done some test renders using complex lighting, with GI, AO, and a little SSS on a couple materials.
So I started one, shut the monitor off, went to sleep.
Next day, after 6-8 hours of rendering, it's less than 1/4 of the way done.
If it gave me even an un-accurate estimation of render time say, 45 hours, then I'd make adjustments before I start rendering at all.
As it stands, the way I find out the render times are so overcooked, is by wasting 6+ hours rendering, only to stop it before its through.

[dann_stubbs]

Well this is sort of the problem with this.
I realize that estimated render times are only a "ball park" figure, if that.

I can't estimate per-frame, because I'm not doing animations, only stills.
So I can only guess based on how long it takes each renderline to advance.

All I would want it for is to know if it's even feasible to continue with the render, or if I need to make adjustments that will give me render times that are even remotely acceptable.
Because I've done some test renders using complex lighting, with GI, AO, and a little SSS on a couple materials.
So I started one, shut the monitor off, went to sleep.
Next day, after 6-8 hours of rendering, it's less than 1/4 of the way done.
If it gave me even an un-accurate estimation of render time say, 45 hours, then I'd make adjustments before I start rendering at all.
As it stands, the way I find out the render times are so overcooked, is by wasting 6+ hours rendering, only to stop it before its through.

it still can't be accurate since say you are rendering a single thread cpu - if the top of the frame is simple the time will be off and as it gets into the lower frame where the complex geometry is the time will shoot up.

if rendering a large image or even a still of average size to get an estimate reduce the image by 1/4 and render that - then you can times the render time by 4 to get a better estimate of the full size render. if your small test image still takes too long then you can reduce it more say 1/10 and then times by 10 etc... it is not perfect but it does provide at least something reasonably close to the larger version of the image. not always perfect with GI etc since samples then will be way too dense in the resulting small test image most likely but the calculation times may still be similar enough to use as a gauge on the full size - do a few tests on your images and see how the results match up

i saw a renderer once (i think it was lightwave many years ago?) that rendered a tiny 160x120 version of each frame to get an estimate of the image time - but it took so much time to render the small test time preview (in addition to the then full frame) that most people just turned it off.

dann

[Dtox]

it still can't be accurate since say you are rendering a single thread cpu - if the top of the frame is simple the time will be off and as it gets into the lower frame where the complex geometry is the time will shoot up.
I'm on a G5 dual, so it's not a single threaded render.
I guess I'll just have to use the method you've provided.

You'd kinda think that Maxon would have some sort of function for you to calculate an estimation even if it isn't accurate.

[Dtox]

Oh, yeah, thanks for the advice. Appreciated...

[Srek]

You'd kinda think that Maxon would have some sort of function for you to calculate an estimation even if it isn't accurate.
What help would an estimate be that has an error margin of several hundred percent?
I'm sorry, but Dann is spot on, there is no reliable way to determine rendertime in any usefull way beforehand.
Cheers
Björn

[Dtox]

I believe that Dan is spot on.
That's why I'm adopting his method that he was generous enough to share.

As to what use a rough estimate with highly fluctuating accuracy would be, possibly in a scenario as Dan described that Lightwave used to have.

3dsmax has this function. As in-accurate as it may be, when I used Max years back, I wasn't doing highly complex scenes, but I did use the render estimate which did actually prove useful.
Such as when you're creating an object that will be merely a part of a bigger scene.
Since you aren't really using any global rendering scheme, regular objects with a temporary light scheme render faster.
And having an estimate from something with a moderate render time gives you some numbers to use in further estimation, even if it is just an estimate.
If there are no real dynamic elements to the object, you could get a reasonably close estimation for how much time that object will theoretically occupy in the full scene.

Because if render time estimation has absolutely no use, why would other apps even bother with it?


If you had a scene that had some reflections in the middle of the frame that were consistent to some degree and extended down to about 3/4 the frame, you would be able to at least have a rough idea of how long the center of the image with reflections would take to render without having to calculate it by hand.
Or even possibly with render regions, render small parts of the image selectively, let them render to see how much the time fluctuates, if there's a reasonable degree of fluctuation you can use that data in a final estimate.

I understand that Cinema just doesn't have this feature, that's fine I'll get over it.
I'm not saying Maxon is incompetent because of it, or that it's a lesser app than one that has this feature.

I'm just saying that it potentially could have some use.
I don't think it's just downright useless in all situations as Srek has so arrogantly implied.
jk kidding Srek.......

[eldonaldo]

you can do cheap estimations with lower resolution renderings and the assumption that rendertime scales proportionally with the output-resolution (number of pixels sampled).. so if you have, say, a preview that is 250 x 250 px in scale and renders 3 minutes - that is 1 minute per sampling ~ 21.000 Pixels.
If your final render output is 4000 * 4000 the estimation based upon the preview is 760 minutes (~ 12h).

I know that this way of estimating works relatively precise for PPT-renderers - as far as scanline-renderers, that work with adaptive image-sampling, im not that sure..
but it should work quite well nevertheless. Just make sure that the resolution used for your testrender isn't too low - it should be at least 320*240.

[nycL45]

I low tech it: eyeball scan lines total movement (inches), calc remaining time and add 15%.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.