On Sat, 06 Feb 1999 08:52:17 -0600, "Thorsten Froehlich"
<fro### [at] charliecnsiitedu> wrote:

>In article <36bd807b.4891785@news.povray.org> , pet### [at] usanet (Peter
>Popov) wrote:
>> 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?
>
>Well, for experienced users that migth be the case, but I got horrified when
>thinking of all the new users posting bug reports saying that POV-Ray is
>slower than it say, and then they ask what is wrong or even make bug reports
>out of it...

Heh heh I guess you are right, but then again, using the current and
average-up-to-now means that the "estimate" is updated realtime...
which renders kind of senseless. OTOH, the more accurate mosaic
preview-based one might turn out to be a good idea.

<snip!>

>> 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
>
>It is possible, but all first run pixel values would need temporary
>storage...

Why? There's file output for this purpose, right? That's the main
idea. D/l a pic, it's edgy, d/l the source and do an anti-alias render
of it with. It should take several percent of total render time.
Render at higher resolution? OK, but why recalculate already rendered
pixels? Use a 320x240 input file for a 640x480 render and you save 1
in every four pixels. Cool, isn't it?

>> several advantages over the current implementation:
>> 1) instead of the up-and-left-only aa check all adjacent pixels will
>> be checked
>
>Hmm, I don't understand what you mean by "up-and-left-only aa check".

Last time I've throroughly read the docs on non-adaptive anti-aliasing
it said that if a pixel differs from its left and/or upper neighbour
by more than a certain amount of r+g+b (0.3 by default), both are
anti-aliased. This makes sense since the ones to the right and below
would not be rendered at the time of this check.

>> 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
>
>Are you sure you know how the adaptive anti-alias in POV-Ray works? This
>sounds like you want to do it the same way :-)   Maybe I misunderstand
>you!?!

Of course I know :) Tell me this, can you render your favourite, for
eg., 1024x768-35-meg-source-with-media-and-a-zillion-glass-spheres
scene with +am2 +a0.5 and, if  after 165.34 hours of rendering during
you Hawaii vacation  you see is pixels and jaggies, you re-render it
using +a0.25 +am2 and it takes, say, 3h only? Currently, no. You'll
have to re-calculate all that stuff that's already there and only
about 5% more, which is a real waste of CPU time and neuron cells.

>> 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.

>This would be possible without the AA option as well...

Yes but it would be jaggy.

>     Thorsten

Regards,
Peter

Post a reply to this message