If not, is there a way to estimate it (i.e. do any logs show how many chunks it will render, and then averaging the time it's taking to render x amount of chunks...understanding that it is only an estimate, and some chunks take longer than other chunks...)

[reason I ask, is I just started a render...and it seems like it is going to take long.  I need to know if it is like 16 hours long, or 3 hours long timeframe?]

I have been working on a Python add-on that will tell you this info, based on previous renders of the same scene, and assuming that you're about to do a bigger or smaller size. It's actually a utility to quickly change render size. But I thought it would be handy to know, as I'm mouse-wheeling to larger sizes, some sort of prediction of how long that will take to render.

Well - let me tell you, that even with no changes in the scene or render settings, it is incredibly difficult to predict how long the next render will be. The only thing that is for sure is that more pixels will take more time to render. But how much more is a non-linear function. I have tried to characterize this function through many experiments but it is discouraging. I am only able to get approximately 30 to 40% accuracy. For example, if a 500x500 (25 KPixel) render takes 6 minutes, and you then double the dimensions and now you're going to render 1000x1000 (100 KP), you'd think that would be 24 minutes becomes it's 4 times more pixels. It's usually actually around 18 minutes. Conversely, if you do a full render and it takes an hour, then you decide to do some more tests and drop to half size, it may still take almost half an hour. Weird.

If, on top of that, you change render settings or content, or even camera angle, it would be even more inaccurate.

So - as far as I know, there is no easy way to accurately estimate as a pure prediction.

Your idea of examining a log or something and getting % complete (from which you could estimate remaining time) would be cool but I'm not aware of anything going on like that behind the scenes.

Python scripts get absolutely no opportunity to even do some work during the render, even if the progress info was available somewhere.

I wonder, now, if the buckets get written to a file in a way that we could measure the file size. Hmmm - I'll have to think about that. It would have to be an outside tool though - or you'd have to use render in background to make a Python script running inside Poser be able to do it.

I'm afraid that there is just too much variation in the render-time per bucket. Sometimes one bucket determines the total rendertime. Halving bucket size then speeds up the thing. Etcetera.

Vue guesses the rendertime to go, based on the idea that all buckets are equal, or something. In images with strong local reflections / refractions, it can be 200% off easily.

...but if the estimate comes out to be 2 hours, and its 200% off and it really is 6 hours, I would at least know I didn't set something wrong and it is estimating 16 hours.

My guess is it would always estimate lower than what it would be.

I chatted with SM Tech support a little while about it.

At least in P9, rendering is done in memory, I could find no temp files being made or changed, there is logging you can tun on in the INI, but they dont think it logs render info, the progress bar is basically dividing your scene by buckets (i.e. bucket of 32 = 32x32px, so a scene of 800x600 = 469 buckets) and moving after each bucket is completed.  Nothing is going out to debugview.

So...only option I can see would be "Spying" on the progress bar, and tallying a running average per bucket of the progress bar...using that to estimate "time to completion", which would get more accurate as the render goes on, in most cases.

To be honest, if they just updated the Progress Bar window with the render Start Time, and a "ruler" (i.e. like 1/4, 1/2, 1/3 marks) along the line, you could just estimate it quickly in your head...

In fact, it would not waste much processor time at all to do the simple math at the end of every bucket to update a running "Average Time per bucket" and a "Estimated Time to Complete" should be quite easy

If it started at 12 noon, (100 buckets) and 1st bucket took 5 minutes, second took 10, third took 15, then at end of third/start of fourth, they could update display:

Render Started: 1200
Buckets Remaining: 97
Avg Time/Bucket: (30/3) = 10min
Estimated Time left: (97x10min) =>16.16 hours

Of course, it should not give an estimate until it gets started (i.e. 10 buckets or so), similar to how windows does when copying files.

It's not like copying files. Watch any render as it happens on the screen, it's anything but uniform. It's add dependent on the calculations needed for the segment of the scene being rendered. Shine a light on a flat surface and render, now add an object with a transparancy, another with a bump, another with a displacement, another with all three and a relfection, sepearate them and render now move them around and let them pass in front of one another render again, same scene, different rendering time, different calculations needed.

...but have you ever download a file from the internet, and it estimates right off that it will take 1 hour.  You come back in 1 hour, and it says it still has 1 hour left?  OK, sure it was WAY off, but you knew it was AT LEAST 1 hour, and you left it and did something else...

Now take the same example of downloading a item from DAZ and it says "unknown size" and you have no idea if it is 5k or 52gb?  Do you leave?  Do you stay?  Who knows...after a half hour you are thoroughly irritated, that you could've just had a snack and got the mail.

In this case, it will probably always estimate the "best case", so the minimum amount of time required (since its rendering the top corner of the scene 1st which probably represents a pretty "easy" render portion).   I would argue that is at least a good thing to know!

...and really, what harm does it do?  Worst thing is people ignore it. :tongue1:

the daz freebies are usually under 50 MB, excepting apps like D|S.  if using poser 9, my guess would be to limit raytrace bounces to 4 in a large render on a normal machine.  16 hours is too long for one of these IMVHO, if the difference between a 16-hour render and a 2-hour render isn't noticeable.

@3doutlaw: I support your suggestion. Maybe we can get an optiop to switch this info on/off as it might confuse newbies etc. Plus the notion that we get this info only if the estimated total render time exceeds ... minutes, to avoid info overload at short renders. Whatever, good idea.

Thanks, I have formally submitted a feature request via SM Tech Support.  Maybe they can sneak it into poser 10/2014?  :)