Hi,
when I use anti-aliasing and treshold 0.0 (+A0.0) with an empty (black)
scene, every pixel is super-sampled. The doc says every pixel which differs
*more* than threshold is sampled, but that's not true. Try +A0.001: No pixel
is sampled anymore!

Now I use the recursive AA method (+AM2) and use a depth of 2 (+R2). The
messages say: 16.06 (@160x120) / 16.01 (@640x480) samples are taken per
pixel. This is dependent on the resolution, so the pixels in the edges seem
to be handled in a different way. The doc says: At a depth of 2 the maximum
number of taken samples is 25!

Why are the pixels at the edges sampled in a different way than the others
with method 2 (but not method 1)?
Why isn't the maximum number of samples taken?

btw: I use POV-Ray 3.5.
Felix Wiemann

Post a reply to this message

In article <3c6a935b@news.povray.org> , "Felix Wiemann" 
<Fel### [at] gmxnet> wrote:

> Why are the pixels at the edges sampled in a different way than the others
> with method 2 (but not method 1)?
> Why isn't the maximum number of samples taken?

Who cares as long as the result is free of errors?

If you want to know how AA works, take a look at the source code.  It is not
like everything has changed in 3.5 :-)

    Thorsten

Post a reply to this message

Has the Team ever considered adding more AA methods? It'd be nice if you
found one that handled very thin lines a little better.

Post a reply to this message

Felix Wiemann <Fel### [at] gmxnet> wrote:
: when I use anti-aliasing and treshold 0.0 (+A0.0) with an empty (black)
: scene, every pixel is super-sampled. The doc says every pixel which differs
: *more* than threshold is sampled, but that's not true. Try +A0.001: No pixel
: is sampled anymore!

  I think that's just a colloquial terminology thing. It wants to say that
if(difference_between_adjacent_pixels >= threshold) then supersample.
  However, that '>=' is more difficult to express in fluent english than
just "more than".
  Of course it could be said precisely, but it would require a rewording of
the expression. Instead of being something like
  "If adjacent pixel colors differ more than the given threshold..."
it would need to be something like:
  "If the difference in color between adjacent pixels is more or equal to
the given threshold..."

: Why are the pixels at the edges sampled in a different way than the others
: with method 2 (but not method 1)?
: Why isn't the maximum number of samples taken?

  As Thorsten said, who cares as long as it gives a good result?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Tony[B] <ben### [at] catholicorg> wrote:
: Has the Team ever considered adding more AA methods? It'd be nice if you
: found one that handled very thin lines a little better.

  You are welcome to suggest an algorithm for that.

  The problem in raytracing is that rays are infinitely thin and they cover
only an infinitely thin volume of space (they are 1-dimensional). However,
the distance between pixels is huge compared to that. If an object is much
smaller than a pixel then there's a big chance that no ray will hit it.
There's no way the renderer can know that the object is there and that it
should shoot rays towards it. (After all, the reason to shoot rays through
pixels in the first place is to see if there's some object in that direction.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On 13 Feb 2002 12:51:24 -0500, Warp wrote:
> There's no way the renderer can know that the object is there and that it
> should shoot rays towards it. (After all, the reason to shoot rays through
> pixels in the first place is to see if there's some object in that direction.)

Actually, there is a way: the vista buffer.  But there's no way to know what
percentage of the pixel that object will take up or how it should be shaded
without shooting lots of rays at it.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

On 13 Feb 2002 12:47:46 -0500, Warp wrote:
>   However, that '>=' is more difficult to express in fluent english than
> just "more than".

"at least"


-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

In article <3c6aa79b@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   You are welcome to suggest an algorithm for that.

Hmm...sample initially in a cross or x pattern to find out if a thin 
object goes through the pixel? If one is found, supersample the entire 
pixel. It would be slower than the current adaptive method, because the 
minimum samples per pixel would be higher, but should be faster than the 
completely non-adaptive method.
Also, a multiple pass method might be interesting...render with no or 
very little antialiasing, then run additional supersampling passes. A 
faster preview, and you could let it refine the image indefinitely. A 
pixel could be supersampled if any of the nearby pixels hit an object 
but it didn't.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , Christopher
James Huff <chr### [at] maccom>  wrote:

> Hmm...sample initially in a cross or x pattern to find out if a thin
> object goes through the pixel?

Won't work well:  Remember that the ray is infinitely thin, so you will have
some spacing between rays.  Of course, you can make the sampling so small that
is scratches floating-point precision, but I doubt this would really improve
quality.

What can be done with every object with a known surface is to find a few
points on the surface and then start sampling from there (so doing AA with
superpixels first).  It would work for all objects with a single surface or a
number of parts/surfaces assuming you can supply one point for each of them.
However, I don't even want to make any guess about the speed to expect from
such a method.  Not to mention it would only work (in finite time) for primary
rays.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Actually, there is a way: the vista buffer.

  Does it work for reflections/refractions as well?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message