Peter Popov <pet### [at] usanet> wrote in article
<36bd807b.4891785@news.povray.org>...
> On Thu, 04 Feb 1999 23:14:48 -0600, "Thorsten Froehlich"
> <fro### [at] charliecnsiitedu> wrote:
> 
> >For the mosaic preview part that might be possible (and help to do the
> >general prediction). Any other prediction of the render time based on
the
> >lines rendered so far (the only "easy" way I can think of) is not very
> >useful for most scenes. For example you might have just a sky in the
upper
> >half of the image which renders fast, and the, in the lower part you
might
> >have a few hundret glass spheres, using a high max_trace_level and
> >anti-aliasing the first line that intersect a few of the spheres might
take
> >a few times what the whole image took to the middle...
> 
> I know, that's why I am suggesting an estimate to be made based on
> both speed reports. The mosaic preview will be the most accurate, but
> then again, even a faked estimate is better than none at all, right?


I would have to say NO to that. A faked estimate is far worse than none. It
fools you into thinking you know how long it will take, when you actually
have no idea!

> 
> >I usually use a very small preview image (like 32 * 24 for a 640 * 480
> >image) with the _same_ options I will use for the final image and
multiply
> >the time it took for the small one to estimate the final render. Most of
the
> >time an additional factor of 1.05 to 1.1 is needed to account for
background
> >system tasks etc.
> 
> Antialiasing takes longer on smaller images if you account for
> samples/pixel. AT least that's what my practice shows. I usually
> render a 160x120 no AA, multiply the render time accordingly, multiply
> it by [1+AA/3] and add it to the parsing time. Usually works pretty
> fine, but why should *I* bother if the box can do it for me?
> 
> Come to think of it, can antialiasing be made *after* the image has
> been traced? I.e., scan the pic and apply aa where needed. This has
> several advantages over the current implementation:
> 1) instead of the up-and-left-only aa check all adjacent pixels will
> be checked
> 2) one can see if aa is needed at all. Then one can do a pass with a
> large threshold (0.5 for eg.) and lower it until the result is
> satisfactory. If parse time is much lower than render time, this is a
> pretty time-saving approach
> 3) dual processors or two computers can be easily made to work in
> tandem with the field interlace option (two pov instances in the first
> case), then one of them will only do the aa pass.
> 
> >    Thorsten
> 
> Regards,
> Peter
> 
>

Post a reply to this message