Xplo Eristotle wrote:
> 
> That's not quite how I remember it working, and performance seems to
> support what I remember, but my memory is imperfect. I suppose I'll have
> to look at the docs again.

I've checked the docs again, and it seems to me that what's happening
(using type 2 AA) is this:

AA essentially functions (as most of us likely know) by averaging
several values for one pixel. It is generally understood that
transitions with less contrast don't show aliasing as much, and so to
save time POV-Ray's algorithm allows for a threshold below which no
extra rays will be shot. In theory, contrast values below the threshold
will be invisible to the human eye, or too small to fit within the
digital range of the output image.

Obviously, when averaging values for a pixel, the more values you
average, the more accurate the result will be. This accuracy is
determined by the recursion depth. The adaptive algorithm saves time by
not calculating values for areas believed to be the same and instead
focuses in on edges, taking samples where they're significant and
ignoring or interpolating (I don't know which) theoretically-contiguous
areas, until it reaches the recursion limit.

Fine. This is great, but it's not quite what I'm proposing.

Let us assume for sake of explanation that we are antialiasing a
specific pixel containing a hard transition from white to black. This is
a pretty harsh transition (in fact, it's about as harsh as they get) and
a lot of values will need to be averaged in order to find an acceptable
result for the pixel. (Anyone who's tried antialiasing harsh transitions
using low-sampling AA settings can confirm this; the antialiased edge
comes out looking a little choppy, even with jitter turned off.) POV-Ray
already handles this kind of situation well.

However, now let us assume that the same transition is being made, but
from white to light gray. (Let us further assume that the transition
would appear aliased to the human eye, and that the contrast value is
over the AA threshold.. a reasonably common situation, really.) In this
case, as I understand it, POV-Ray will treat the transition exactly as
it treated the previous one, using the same algorithm and finding
exactly the same number of pixels. The problem in this case is that
POV-Ray is tracing rays to find a value that's far more accurate than it
actually needs to be; just as no antialiasing is good enough in
very-low-contrast situations, low-quality antialiasing is good enough in
somewhat-low-contrast situations. Nevertheless, POV-Ray treats light
gray and black as being exactly the same for its calculations.

What I'm proposing, then, is a way (algorithmic or user-defined) to
adjust the recursion level according to contrast. That way, scenes with
a lot of high- and low-contrast transitions effectively render at the
speed of the lower-quality AA, only slowing down when it reaches a
high-contrast area. (Most scenes are like this, but for an extreme
example, consider a concrete wall with signs or expansion breaks or
sharp shadows falling across it or something: you have a lot of
low-contrast area, where normals and small color variations keep the
concrete from being a solid color, with a few high-contrast edges that
represent a tiny portion of the scene.)

Now that I've typed all that out (phew), is my proposal in fact what
POV-Ray already does, and the docs just do a poor job of explaining it?
Or would this be a new enhancement? If the latter, does it make sense to
anyone else, and do you think it would have a significant effect on
render times?

-Xplo

Post a reply to this message