Shaderlight

Rendering Time Estimate

 
R.Thur
Total Posts: 12

Hi, hopefully someone still reads the forum!

I was wondering if it could be possible for Shaderlight to estimate the rendering time based upon system spec, model & texture settings, and output resolution etc. For example, if I set resolution at 1920x1080 and ‘X’ quality, shaderlight can calculate whether this render will take 6 hours or 26 hours, before I start the rendering process? Would not need to be too accurate, perhaps just a rough estimate.

This would really help with planning workflow! Sometimes I get my guess at render timing quite wrong and find myself without a finished render in the time required. Not often but occasionally.

Just a question, I don’t know if this is possible.

EGIE
Total Posts: 504

Hi R.  - this is a very good suggestion !!!

Yes, this render time estimation would be a great feature indeed!

I always produce a test render first with a lower resolution like 1920 x 1080.
This fast render result is necessary to see if all materials or the lighting etc. are ok.
It would be most annoying to detect errors after many hours of render time as you can
imagine ;-)

My test render gives me the needed render time as well, based on the amount of rendered pixels.

So, if my test render with 2.019.600 px needs 45 minutes for instance, my desired render resolution of
3960 x 2040 px (which are 8.078.400 px) will roughly need 180 minutes to render.

Although this is also only a rough estimation of course, mostly this estimate fits to me pretty
good and let me plan my production time and workflow.

BTW: I always read the forum!!!!  ;-)  but your apprehension fits - it’s pretty quiet here…

R.Thur
Total Posts: 12
EGIE - Oct 07, 2016 05:28pm

Hi R.  - this is a very good suggestion !!!

Yes, this render time estimation would be a great feature indeed!

I always produce a test render first with a lower resolution like 1920 x 1080.
This fast render result is necessary to see if all materials or the lighting etc. are ok.
It would be most annoying to detect errors after many hours of render time as you can
imagine ;-)

My test render gives me the needed render time as well, based on the amount of rendered pixels.

So, if my test render with 2.019.600 px needs 45 minutes for instance, my desired render resolution of
3960 x 2040 px (which are 8.078.400 px) will roughly need 180 minutes to render.

Although this is also only a rough estimation of course, mostly this estimate fits to me pretty
good and let me plan my production time and workflow.

BTW: I always read the forum!!!!  ;-)  but your apprehension fits - it’s pretty quiet here…

Interesting, thanks. Do you find that estimating your rendering time based on number of pixels is accurate enough? It does make sense.

EGIE
Total Posts: 504

Hi
since I understand nothing of render algorithms of course, I began to observe the pixel quantity - somehow this (amateur!!-) theory suited to me pretty well so far (which can be accidental :-) )

Also I never use the 100% quality setting - maximally 90% and often 80%, instead I render in a higher resolution always, which gives me a much better postpro quality option later…

I also always hide all geometry and especially all light fixtures, which is/are not necessary for the current render task.

So I almost never had any render lasting longer than about 1,5 hour…

And, as I said, I always do a HD test render before

kfoojones
Total Posts: 275

Hi,

Unfortunately, it isn’t really feasible to estimate the time required before starting the render – there are just too many variables and small changes can dramatically change how long a render will take. Just changing a material’s properties, or moving an object so that a particularly complex area is covered or uncovered, can change render times by a matter of hours.

Although there are some rules of thumb that you can use to guess how long a render is likely to take, they don’t cover all possibilities and can be wildly misleading. In the end, we decided it was better not to attempt to provide estimates that users might come to rely on and then be unpleasantly surprised one day when they are up against a deadline! This is one of those areas where a human can, with experience, give a better estimate than a computer.

As EGIE has suggested, you can make a reasonably accurate estimate after rendering has started because pixels that are still to be computed are likely to be similar to ones that have already been rendered.

One thing we could look at doing is trying to provide an estimate of time remaining as the render progresses. We haven’t done that to date as the estimate is likely to be quite inaccurate until a large percentage of the render is complete and we don’t want to risk misleading and disappointing people. (In the example EGIE gives, it takes 45 minutes to get a reliable estimate.) It would be interesting to hear whether that kind of estimate would be useful and what you think would be an acceptable error. Bear in mind we also have to consider users who don’t read this forum or the documentation and therefore aren’t aware of the caveats.

Thank you,
Shaderlight support

R.Thur
Total Posts: 12

Thanks for the replies. Yes I have started trying to use EGIE’s suggestion about time relative to pixel count which seems to be close enough for my needs. I always run several low quality renders when setting up a scene to gauge the lighting effects, but I’ve never run a full quality / low pixel to estimate time before, as this does take some time with my scenes. So at 100% quality and 1280x720 it can take up to 2 hours to finish which isn’t always feasible while i’m in the middle of the working day, but that does then tell me that my final render will take over 24 hours - which is useful especially if I need it the next day.

I did think that any shaderlight estimate would have to be based upon previous test renders with no changes to the scene - that seemed obvious! :) But yes I would have thought that this could not be implemented as a 100% exact science in any case. Any estimate would have to provide a margin of error, which would probably increase pro rata with the total amount of hours estimated.

R.Thur
Total Posts: 12

“One thing we could look at doing is trying to provide an estimate of time remaining as the render progresses. We haven’t done that to date as the estimate is likely to be quite inaccurate until a large percentage of the render is complete and we don’t want to risk misleading and disappointing people. (In the example EGIE gives, it takes 45 minutes to get a reliable estimate.) It would be interesting to hear whether that kind of estimate would be useful and what you think would be an acceptable error.”


I should have answered this question a bit more directly probably!

I think this feature would be most useful. Could it be made to fluidly change / become more accurate as elapsed render time increases, and perhaps give an accuracy rating based upon the length of elapsed processing time, expressed as a percentage? If anything this may also mean the ‘test’ render doesn’t need to be run to completion, meaning a more efficient way for the user to estimate the final render time using EGIE’s method.

Hope this makes sense…

Joachim
Total Posts: 20

I just wonder how accurate this estimate would be. It’s not so uncommon to have more complex geometry and/or reflections near the bottom of a render. If the estimate is calculated based on the finished part, it might still be quite a bit off.

I must say that a small render can give a pretty solid estimate.

I tested with example below in highest quality. The time doesn’t exactly quadruple with every doubling of the linear size, but it’s in the same magnitude.

400x300: 1’05”
800x600: 3’30”
1600x1200: 12’15”

Joachim

Image Attachments
smeg2.jpg
Click thumbnail to see full-size image
kfoojones
Total Posts: 275
R.Thur - Oct 14, 2016 05:00pm

I did think that any shaderlight estimate would have to be based upon previous test renders with no changes to the scene - that seemed obvious! :)

The only thing you would be able to change whilst keeping a reliable estimate would be the render resolution, which I’m not sure would be sufficiently useful, given that it’s not too hard to calculate in your head? Also, it would be quite difficult for Shaderlight to know whether you’re sending exactly the same render again, as it doesn’t keep track of changes when you’re not in auto-update mode.

R.Thur - Oct 18, 2016 10:00am

I think this feature would be most useful. Could it be made to fluidly change / become more accurate as elapsed render time increases, and perhaps give an accuracy rating based upon the length of elapsed processing time, expressed as a percentage? If anything this may also mean the ‘test’ render doesn’t need to be run to completion, meaning a more efficient way for the user to estimate the final render time using EGIE’s method.

Or alternatively, a range of times? e.g. 1-2 hrs, 12-24 hrs, 1-2 days, etc? The size of the range would represent the accuracy we think we’re reporting. I think I prefer the ranges, because its meaning is more obvious, but I do worry about situations where we estimate 1-2 hours and it takes 3 hours and someone misses their deadline.

Slevin - Oct 18, 2016 11:17am

I just wonder how accurate this estimate would be. It’s not so uncommon to have more complex geometry and/or reflections near the bottom of a render. If the estimate is calculated based on the finished part, it might still be quite a bit off.

Ah yes, I should have made clear that this is only really appropriate for non-tiled renders, so that the renderer is taking measurements from the whole image. I imagined that the use case would be to get a feel for the expected render times of low-res previews while you’re finalising your setup, without having to wait for full renders to complete. Then you can use EGIE’s manual calculation to estimate your full resolution render when you’re ready to go in tiled mode. (There is a bit of difference in render speed between tiled and non-tiled modes, but not usually enough to render the estimates worthless.)

Regards,
Shaderlight support

Joachim
Total Posts: 20

Thanks for your feedback!

Any idea about the accuracy of EGIE’s method and how well it scales?
If you’re only after the render time, it might not be necessary to render in 1080p, if you can already have a good estimate after 10min with a 540p trial.

My test results were on the safe side (time increase factor < pixel increase factor) which is a good thing, but maybe that’s not a rule of thumb ;-)

EGIE
Total Posts: 504

Hello SL Colleagues
these all are very interesting contributions and thoughts here!
I will observe this pixel quantity vs time behavior more accurate in future and report here.

There are still other variables I think :-)
Recently I cleaned up my (too much!!!) system processes, which started automatically at the Win7 start, things like an unnecessary Skype or Dropbox start for example. So I reduced my starting processes almost about 35%. This “cleaning” works wonders for me what I could hear already at the fan of my workstation ;-)
So I often disable also virus protection as well as wlan if my computer must do a rendering over night but nothing else…

and actually and clearly!, also my renderings accelerated significantly by using an other CPU render plugin so far - I will check out, whether all this affects SL renderings in the same way

Best, Egie