 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was playing with AA settings today and it occurred to me that while
high-contrast areas need a high adaptive sampling setting to achieve a
really smooth-looking edge, areas with less contrast can get by with
quick and dirty sampling. To some extent, this is provided for by the AA
threshold.. but could AA further be optimized by adjusting the sampling
according to contrast? For instance, the user could specify adaptive 3
or 4 down to threshold .3, then adaptive 2 down to threshold .1 or so,
and adaptive 1 below that...
At present I have no idea what the interface for this would look like,
or if it would have a significant effect on render times.. I just wanted
to get the idea out and see what people thought.
-Xplo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Xplo Eristotle" <inq### [at] unforgettable com> wrote in message
news:3BA7654F.D3428246@unforgettable.com...
> I was playing with AA settings today and it occurred to me that while
> high-contrast areas need a high adaptive sampling setting to achieve a
> really smooth-looking edge, areas with less contrast can get by with
> quick and dirty sampling. To some extent, this is provided for by the AA
> threshold.. but could AA further be optimized by adjusting the sampling
> according to contrast? For instance, the user could specify adaptive 3
> or 4 down to threshold .3, then adaptive 2 down to threshold .1 or so,
> and adaptive 1 below that...
>
> At present I have no idea what the interface for this would look like,
> or if it would have a significant effect on render times.. I just wanted
> to get the idea out and see what people thought.
>
> -Xplo
AA already has adaptive sampling, ie, it is used only when the contrast is
high enough (see section 5.2.6.5). To summarize, type 1 only uses AA if it
is needed and type 2 not only uses AA but subdivides the image recursively
if there is still a large contrast. So, if an area has a little bit of
contrast, it will only subdivide once (if at all). If a lot of contrast is
present, POV-Ray will not only subdivide further, but only subdivide those
areas where the contrast exists.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers wrote:
>
> "Xplo Eristotle" <inq### [at] unforgettablecom> wrote in message
> news:3BA7654F.D3428246@unforgettable.com...
> > I was playing with AA settings today and it occurred to me that while
> > high-contrast areas need a high adaptive sampling setting to achieve a
> > really smooth-looking edge, areas with less contrast can get by with
> > quick and dirty sampling. To some extent, this is provided for by the AA
> > threshold.. but could AA further be optimized by adjusting the sampling
> > according to contrast? For instance, the user could specify adaptive 3
> > or 4 down to threshold .3, then adaptive 2 down to threshold .1 or so,
> > and adaptive 1 below that...
> >
> > At present I have no idea what the interface for this would look like,
> > or if it would have a significant effect on render times.. I just wanted
> > to get the idea out and see what people thought.
> >
> > -Xplo
>
> AA already has adaptive sampling, ie, it is used only when the contrast is
> high enough (see section 5.2.6.5). To summarize, type 1 only uses AA if it
> is needed and type 2 not only uses AA but subdivides the image recursively
> if there is still a large contrast. So, if an area has a little bit of
> contrast, it will only subdivide once (if at all). If a lot of contrast is
> present, POV-Ray will not only subdivide further, but only subdivide those
> areas where the contrast exists.
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.
If I've inadvertently suggested a feature identical to what we already
have, forgive me ^^;;
-Xplo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have done an AA test with following scene:
#declare contrast=1;
camera{
location <0,1,0>
look_at 0}
plane{y,0
pigment{onion
pigment_map{
[0 rgb 0]
[0.5 rgb 0]
[0.5 rgb contrast]
[1 rgb contrast]
}
scale .02
}
finish{ambient 1}
rotate y*34
}
All renderings were done in 320x240, +J0 with povray 3.1
Here are the results (the numbers in the tables are the Smpls/Pxl that pov
reports in the statistics):
+AM1 +R3
--------
+A0.1 +A0.3 +A0.6
contrast=1.0 8.50 8.50 7.93
contrast=0.5 8.50 7.93 7.13
contrast=0.1 7.39 6.67 1.00
+AM1 +R6
--------
+A0.1 +A0.3 +A0.6
contrast=1.0 35.35 33.91 31.64
contrast=0.5 34.69 31.64 28.89
contrast=0.1 29.46 26.74 1.00
+AM2 +R3
--------
+A0.1 +A0.3 +A0.6
contrast=1.0 16.05 16.05 16.05
contrast=0.5 16.05 16.05 16.05
contrast=0.1 16.05 16.05 1.01
+AM2 +R3
--------
+A0.1 +A0.6
contrast=1.0 136.64 136.64
contrast=0.1 136.64 1.01
This shows that with Method 1 it does matter for the recursion how big the
contrast between the pixels is. Though 6.67 Samples/Pixels with +A0.3 and a
nearly all black picture seems very high to me.
On the other side with Method 2 it does not matter how much the contrast
is, pov will always use the same recursion depth if the threshold is
reached. I think this definiteley could/should be improved.
- Micha
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
