Rendertime estimate? - feature suggestion...

[odd]

I havent worked with TG2 long enough to know if this would yield meaningful numbers...however - what do you think about this:

Once a crop render is complete - along with the current information in the top of the renderwindow, a time estimate for a full frame render is shown - based on the time it took to render the crop area, multiplied with the full image area...?

That way you could choose a complex part of the scene and get a worst case number.

feedback?

[buchvecny]

yeah that could be easily done and would help me with getting good rendertime/quality ratio

[oggyb]

I'll third that

[outpt]

This would be extremely useful...

Also, I'd love to be able to configure the camera movement keys.

Also, terragen crashes when setting a camera position of 0,0,0.

(hey, may as well get them all in one post??)

[Cyber-Angel]

I myself have being thinking about such a feature, but my version you'd have a small drop down box to the right of the elapsed render time clock that you already have at render time; this drop down would allow you to select a estimated completion time clock which would operate in the same one you see when your downloading a file. This estimated render time clock should also have the percentage of the image complete.

This completeness percentage should have two modes:

1. Start from 0 (Start of Render) and work to 100 (End of Render)

2. Start Form 100 (Start of Render) and work to 0 (End of Render) [I have seen this method done with some software installations where they start with the full size of the Program, say 25MB and work there way down to zero].

This process should be aware of how the image is comprised and base its estimate on things like:

Image Resolution

Number and complexity of Volumetric cloud layers

Number and complexity of population instances in an image

Global Illumination and Atmosphere Samples and other settings

Ray traced Shadows

Complexity and Number of Displacements etc.

Regards to you

Cyber-Angel

[Oshyan]

A reliable "time left" indicator for renders in TG2 is virtually impossible given the variety of scenes and factors involved. The best way to deal with this is just to do a very low detail render of the same scene *at your target resolution* and then multiply the results appropriately depending on your final main Detail setting. All other settings (cloud samples, etc.) would have to remain the same. The exact formula is honestly unclear to me since my own tests have shown some variability. But in theory 0.1 detail should be 100 times faster than 1.0. I have seen it vary between 50 and 100 times, for some reason. But that may give you a reasonable starting point.

- Oshyan

[Njen]

I wouldn't say virtually impossible. Everyone knows a "Time Left" feature will be technically incorrect, but it would help, in my opinion. A lot of other renderer's have this feature and there are no problems there. All you have to do is multiply the number of pixels rendered at any given moment by the time taken so far at each step, then find an average of those values with every new step (step meaning when a new mini area gets rendered, as it looks like TG2 renders the shape of polygons).

Might I add in that other renderer's also have a wide variety of scenes and factors involved, but it doesn't stop them from estimating the time left to render.

[odd]

The best way to deal with this is just to do a very low detail render of the same scene *at your target resolution* and then multiply the results appropriately depending on your final main Detail setting. All other settings (cloud samples, etc.) would have to remain the same.

..something that TG2 could do for us and present in the render GUI once a first render is made. A full frame rendertime estimate based on the numbers you quoted and maybe even updated when a new render detail number is set or frame size is changed.

However...

..that would most probably incur a lot of extra coding and open multiple cans of worm...so why not just having a simple "full frame rendertime approximation" value in the top of the renderwindow when i complete a CROP render. (I.E showing crop rendertime divided with the crop area and then multiplied with full frame area) That wouldnt touch the general UI and should be pretty easy to implement. Please correct me if Im wrong.

//O.

[The Geostation]

I am be inclined to agree with Oshyan.   However, the first rendering pass (with the dots) is a good way of working out an initial approximation about the total rendering time - I'm finding that the first pass probably takes about 1/10th of the total render time.

While such a feature would be nice, I'd rather see some other features added (such as transparent water and distorted perlin) beforehand.   Also I reckon that amount of time used to derive an algorithm for semi-reliable estimation would be better spent elsewhere.   So I would recommend taking the first-pass time and x10.

Andrew Randle
The Geostation

[odd]

..thus my hope for a simple solution that is easy to implement so not to take away from the important stuff 

[Dark Fire]

However, the first rendering pass (with the dots)...

I have found that with maximum quality settings T2TP seems to render almost everything first and then fills in the few black dots left, thus making this estimation useless.

I have a feature in one of my programs for the old TG that estimates rendering times for animations based on the length of time frames have taken to render so far. I wouldn't think that implementing some time estimation in Terragen itself would cause too much trouble.

All you have to do is multiply the number of pixels rendered at any given moment by the time taken so far at each step, then find an average of those values with every new step (step meaning when a new mini area gets rendered, as it looks like TG2 renders the shape of polygons).

I am inclined to think that the above idea would be the best, giving a live estimate of the time remaining. Terragen could easily go beyond my easy time averaging and look at tendencies and standard deviation and stuff like that to produce a very accurate estimation. It could even give an estimated margin of error for the estimated time remaining.

I am not so sure about the original idea, however, of basing the estimation on a crop. That would waste time as TG would have to consider objects outside the crop to even give a rough estimate.

[Oshyan]

I'm afraid that anything even close to an accurate estimation is far more difficult than you might think. Keep in mind that not all rendering systems or methods are conducive to accurate render time estimations. Some systems are much more consistent across a frame in terms of how long elements take to render, for example. It really depends on what you're rendering and how you're rendering it.

In TG2's case things can vary quite dramatically, especially between sky and ground. So what you're arguing for is the *illusion* of knowledge about render time, not any real information as to how long you should expect to wait - it could easily be 10 times longer or 10 times shorter than even the best estimates would indicate. So what is the value in it?

As I said the best method is to do your own simple estimate with lower detail levels. This could be handled natively in the application for an added nicety, but it will definitely be a lower priority given how easy it is to do your own calculation. We may at some point publish some kind of table of real-world measured tests to allow more accurate estimation on your own, and this is the kind of thing that could form the basis of a tool to estimate final render time based on a lower detail version, but this may well be something that would come after final release (in a patch for example).

- Oshyan

[Dark Fire]

Terragen is based on maths so I'm sure it would be possible to write an external piece of software that reads the tgd file and uses a load of complicated mathematics to analyse settings, objects and other stuff to give a reasonable estimate for the render time. However, a program like that would be very complex and it would have to be thoroughly tested as well as regularly updated. Unfortunately, that would require a lot of time and effort and would still only produce an estimate.

[MeltingIce]

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.

[Njen]

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.

This is not true, none of analyzations are necessary. While a render estimate is just simply that, an estimate, it is not really as complicated as what you are making it out to be.

For example, you have an image that is 100 x 100 pixels (10,000 pixels all up). The first 500 pixels render in the first step, and it takes 10 seconds. The render estimate would now show 3.33 minutes till completion. Then the next step renders, and the next 500 pixels took 20 seconds. The render estimate would now show 5 minutes till completion. The third step renders then next 500 pixels and it takes 20 seconds. Time is now 5.55 minutes. 4th step takes 15 seconds, time is now 5.41 minutes.

That's all there is to it.

Now, if it's a matter of priority as far as features go, then I completely understand it not being added for the time being.