Rendertime estimate? - feature suggestion...

[efflux]

I don't think this is possible because TG can not work out how long the render will take until it has actually gone through the process. It's simply too complicated. There are numerous things that will effect the time. You have to just test render and make a rough estimation of how long the full render will take. You own estimation will be better than anything TG can come up with. I agree with The Geostation. I don't think this is a pressing issue.

[Njen]

That's why it's called an estimate

And TG doesn't have to go through the entire process to work out how long it will take. I explained it in my last post. It calculates how much has rendered so far, and estimates a completion time.

This simplest way I can explain it, is that if TG has completed 1/10 of the render that took 1 minute, then it estimates that the total rendering time will be 10 minutes. Now when it has completed 1/5th of the render completed and that has taken a total of 3 minutes so far, then the estimate now becomes 15 minutes. The mathematics are quite simple.

[Oshyan]

Certainly simple, but as you can see the results are likely to be totally inaccurate. What is the real use of doing such a thing? Especially when the method of rendering at lower detail (but same resolution) can yield a more accurate estimate.

- Oshyan

[Njen]

The results are only inaccurate because I didn't average the end results (I tried to keep it simple for efflux). Plus I only used 2 steps in my last example. In my example before that I used 4 steps and you could see that the estimated time didn't change much by the fouth step.

When TG2 renders, it takes many, many steps (other 3D programs call them buckets, but TG2 does not render steps in any ordered fashion or shape, thus they are not truly buckets), which would, when averaged, provide a far better estimation.

Doing a low res render then a high res render, not only is redundant (waste of render time), but would only serve to provide a barely usable estimation. If I had an image 720 x 405 that rendered with a Detail of 0.1, and AA of 2 and it took 1 minute. How does that tell me how long a render with a Detail setting of 0.7 and AA of 4 will take? It could take 10 minutes, or 60 minutes...

Don't get me wrong, I am not trying to make a big deal out of this, just trying to lay to rest the claims that it is a difficult thing to do, when it is quite simple

[Oshyan]

You could just as easily construct a theoretical scene where the estimate is completely off, for example one with a lot of water and a simple sky, where the top half will render extremely quickly and then slow down dramatically on the water. There's really no such thing as an "average scene", especially when displacement and volumetrics are involved. So although your method may be reasonably accurate (within a 25% margin of error let's say) on some scenes, it would certainly be dramatically inaccurate on other scenes.

The question isn't whether it can be done, as your method is obviously fairly simple, it's whether providing such information is worthwhile and useful or simply misleading. It could as easily upset or put off many people when they see drastically incorrect estimates. Meanwhile the benefits are questionable since it's only in the latter half of the render that the estimate even starts to get close to accurate, and by then you ought to know if you want to keep it with or without such an estimate.

- Oshyan

[Njen]

This will be my last post on this topic because it's late and alas I must sleep

First of all, I understand that there is no such thing as an average scene. I've been working in 3D for well over 10 years, and have rendered everything from shaggy bears to bullets firing out of a gun to penguins to vast landscapes. I have used many 3D packages in my time.

I understand that there are areas of an image that are faster to render than others.

I also understand that the 3D packages that have had a render estimation feature have helped me manage my time more efficiently, let me know if I have overstepped my allotment of render time by estimation. It's as simple as that

[Oshyan]

That's perfectly fair. It's definitely a feature we'll look at implementing and we will do so if it is feasible to provide something that gives reasonably accurate estimates.

- Oshyan

[Ricowan]

The problem with estimation is the same as with continuing a partial render.  TG2 does not currently render pixel by pixel.  There are areas of some scenes I've rendered recently where an area is rendered three times!  Once, with background atmosphere, next was terrain, and finally was water.  The pixels in that area had three different values at three different times during the render, not counting the initial black.  Where does that come into the estimate calculations?  What about the GI calculations that happen before any "real" pixels are calculated? 

Rich

[Dark Fire]

You also have to remember that almost every spec in your computer will make variations on the render time, even including stuff like hard drive optimization if your render is complicated enough.  In order to make an estimate, the program would have to analyze your CPU, RAM, and motherboard, and then every background task your computer is running, your operating system, and countless other things.  I have to agree with Oshyan on this one, I think this feature would be near impossible to implement.  After awhile, you get a feel for how long things are going to render anyways.

That's why I said it would need to be thoroughly tested and regularly updated - you would need a huge range of computers to get sample values from to give the initial estimates any real value. You would then need to automatically collect information from users to further improve the results. However, this is complicated further by the fact that some users may be using CPU limiters and/or have changed the priority of Terragen. I think that this amount of programming and data collection would begin to rival Terragen itself in terms of complexity and would therefore be pointless.

I think the rough estimate based on the length of time taken to render the pixels done so far in a picture is the best balance between complexity and accuracy.

[efflux]

One of the problems is certainly that various elements or areas of the whole picture take much longer to render. My opinion is that once you get used to using all the settings then you can make a reasonably good judgment on how long it can take because you can see all the parts in the picture and the settings you have made. By doing a few test renders you can make a better judgement than what the software could tell you. To be of any use the software would have to make estimations about all the various settings and picture components. This would have to be very complicated to equal what you could estimate yourself.

[Dark Fire]

By doing a few test renders you can make a better judgement than what the software could tell you.

The problem is that those test renders require time to set up and run. For those of us who don't have an army of computers to hand but still want to get the most from TG2, these wastages need to be avoided. I agree with njen:

Doing a low res render then a high res render, not only is redundant (waste of render time), but would only serve to provide a barely usable estimation. If I had an image 720 x 405 that rendered with a Detail of 0.1, and AA of 2 and it took 1 minute. How does that tell me how long a render with a Detail setting of 0.7 and AA of 4 will take? It could take 10 minutes, or 60 minutes...

In a way, this topic is related to the topic on the pause/resume option, because they are both to do with problems actually finishing a render. The solution discussed in this topic allows you to see if a particular amount of quality is going to make the render take too long, or allows you to plan around the render. The pause/resume option allows you to come back after closing Terragen for a while, for whatever reason, to resume rendering a frame that was taking too long.

Perhaps the solutions are related to...

[RedSquare]

Well I'm only a simple soul, who would love to see the preview render percentage broken down to include 1% increments after at least 80% so that I would have at least half a chance of working out how long it's going to take to finish. Even 60% added 'cause sometimes you are in the same boat waiting for the 40% to increment upto 80%.

[oggyb]

If this assumption is wrong then forgive me 

I assume that when the preview is rendering, the detail level shown is actually a new render at that higher detail, not a simple percentage of the finished level of detail.  Adding more percentages into the equation would take much longer to get to the finished state. . .

M.

[jo]

Hi,

We've discussed this with the alpha testers previously as well. Basically, when we are able to come up with a reasonably reliable way of predicting render time then we will add a prediction. We can't do that now. Either the prediction would be wildly optimistic and then annoy people when it took longer, or it would be wildly pessimistic and people would stop the render. Sometimes it might be pretty close, but it wouldn't be possible to tell when. You can do just as accurate an estimation right now as we could - look at how much has rendered and then look at how much time it has taken so far. A render time prediction which isn't pretty accurate just isn't useful. You could have 90% of an image render fast and then have an incredibly shiny mirror ball or something in one corner which could take an age to render. It could be the other way around.

I absolutely agree that a render time prediction would be a useful thing to have, but it's only useful and worth doing if it's pretty accurate.

Regards,

Jo

[Cyber-Angel]

I found this paper in PDF format called "Rendering Time Estimation for Real-Time Rendering" by Micheal Wimmer and Peter Wonka which might or might not be applicable which can be found at this link.

http://www.cg.tuwien.ac.at/research/vr/rendest/rendest_egsr2003.pdf

Not sure weather this could be adapted for use in TG2, but then again I am not a programmer.

Regards to you.

Cyber-Angel