Hi all,

the behaviour of anti-aliasing is irritating me:



          -1-

Why is the cylinder of the following tiny scene anti-aliased when using
the options
// +A0.9 +AM2 +R3 -J0.0 +FN +W400 +H300
// start of scene
cylinder { <-1, 0, 2>, <1, 0.03, 2>, 0.03
  texture {
    pigment { color rgb .25 }
    finish { ambient 1 diffuse 0 }
    }
  }
// end of scene

The maximum color difference is (according to the formula in the inbuilt
help, 5.2.6.4): abs(.25-0)+abs(.25-0)+abs(.25-0) = .75, which is less than
.9, so no anti-aliasing should be done. I used 3.5.icl.win32, windows
2000 professional, 933 MHz, 256 MB. Enlarging the picture (in IrfanView)
clearly shows anti-aliased pixels.



          -2-

A totally empty scene, rendered with "+A0.9 +AM2 +R2 -J0.0 -F +W400 +H300"
casts 120701 rays in 0.28 seconds. Change "+R2" to "+R6": this casts the
same number of rays in 6.22 seconds; "+R7": 137.98 seconds. To me this
looks as if the anti-aliasing is done even if difference<threshold, but in
this case the rays are not counted.



          -3-

The inbuilt help 5.2.6.4 says:
   "If this difference is greater than the threshold then both pixels are
   super-sampled. The rgb values are in the range from 0.0 to 1.0 thus the
   most two pixels can differ is 3.0. If the anti-aliasing threshold is
   0.0 then every pixel is super-sampled. If the threshold is 3.0 then no
   anti-aliasing is done."

This is not consistent, it should either be (changes in boldface):
   "If this difference is greater OR EQUAL than the threshold then both
   pixels are super-sampled. The rgb values are in the range from 0.0 to
   1.0 thus the most two pixels can differ is 3.0. If the anti-aliasing
   threshold is 0.0 then every pixel is super-sampled. If the threshold is
   3.0 then ANTI-ALIASING IS DONE ONLY IF ONE PIXEL IS PURE BLACK AND THE
   OTHER IS PURE WHITE. If the threshold is GREATER THAN 3.0 then no anti-
   aliasing is done."

or
   "If this difference is greater than the threshold then both pixels are
   super-sampled. The rgb values are in the range from 0.0 to 1.0 thus the
   most two pixels can differ is 3.0. If the anti-aliasing threshold is
   0.0 then BOTH PIXELS ARE super-sampled IF THEIR RGB VALUES ARE NOT
   EQUAL. If the threshold is 3.0 OR GREATER then no anti-aliasing is
   done."

I would stongly prefer the anti-alias decision being implemented as
"difference is greater than threshold".

Currently I suggest to NEVER use Antialias_Threshold = 0.0; 0.001 should
do the same (at 8 bits per color) and will save VERY much time if the
scene contains areas without change in color. (For example statistics see
my answer to p.g: "What causes this effect" (started by
"mca### [at] aolcom (S McAvoy)").



          -4-

To set a threshold>=1, a leading zero is required: "+A1.0" isn't accepted,
but "+A01.0" is. This is not documented (and should not be neccessary).



          -5-

A trailing ".0" may not be omitted. The syntax is (according to internal
help 5.2.6.4)

   +An.n     Sets aa on with aa-threshold at n.n

The symbol "n.n" is defined as (internal help, 5.2):

   n.n       Any float such as in Clock=3.45

Because 0 is a legal float value, it should be accepted here (ANY float!).



I'm confused ...

   Sputnik

Post a reply to this message

<fr### [at] computermuseumfh-kielde> wrote:

> // +A0.9 +AM2 +R3 -J0.0 +FN +W400 +H300
> // start of scene
> cylinder { <-1, 0, 2>, <1, 0.03, 2>, 0.03
>   texture {
>     pigment { color rgb .25 }
>     finish { ambient 1 diffuse 0 }
>     }
>   }
> // end of scene

This is not a complete scene...

> The maximum color difference is (according to the formula in the inbuilt
> help, 5.2.6.4): abs(.25-0)+abs(.25-0)+abs(.25-0) = .75, which is less than
> .9, so no anti-aliasing should be done.

In your scene, you should have something like a light source.  You cannot
take the color value of an object you enter, you have to take the color a
pixel will have after object finishes, light and all other effects have been
applied.

    Thorsten

Post a reply to this message

> Hi all,
> 
> the behaviour of anti-aliasing is irritating me:
> 
> 
> 
>           -1-
> 
> Why is the cylinder of the following tiny scene anti-aliased when using
> the options
> // +A0.9 +AM2 +R3 -J0.0 +FN +W400 +H300
> // start of scene
> cylinder { <-1, 0, 2>, <1, 0.03, 2>, 0.03
>   texture {
>     pigment { color rgb .25 }
>     finish { ambient 1 diffuse 0 }
>     }
>   }
> // end of scene
> 
> The maximum color difference is (according to the formula in the inbuilt
> help, 5.2.6.4): abs(.25-0)+abs(.25-0)+abs(.25-0) = .75, which is less than
> .9, so no anti-aliasing should be done. I used 3.5.icl.win32, windows
> 2000 professional, 933 MHz, 256 MB. Enlarging the picture (in IrfanView)
> clearly shows anti-aliased pixels.

Well, this is because of the way method 2 works. Method 2 shoots rays at all
corners of each pixel so you get 401 * 301 = 120701. Why you get more than
this number with your example scene is not clear to me.. maybe the colour
difference is calculated as sum from all corners or so. Note that you get a
blurring of the cylinder even when no additional samples are shot (+A02.0
in your example) because the pixels colour are the averaged from all corner
points.


> 
> 
> 
>           -2-
> 
> A totally empty scene, rendered with "+A0.9 +AM2 +R2 -J0.0 -F +W400 +H300"
> casts 120701 rays in 0.28 seconds. Change "+R2" to "+R6": this casts the
> same number of rays in 6.22 seconds; "+R7": 137.98 seconds. To me this
> looks as if the anti-aliasing is done even if difference<threshold, but in
> this case the rays are not counted.
> 

No, this is the pure overhead you get for setting up the array to
potentially store the result values from sampling for the subpixel rays.
Well, this is clearly not programmed optimal but R6 is crazy for almost all
cases anyway. And if you increase the scene complexity you can see that the
overhead remains constat so it doesn't matter too much.


- Micha

-- 
POV-Ray Objects Collection: http://objects.povworld.org

Post a reply to this message

Thorsten Froehlich wrote:

 > In your scene, you should have something like a light source.

 >>    finish { ambient 1 diffuse 0 }

With "ambient 1 diffuse 0" a lightsource wouldn't make much difference, 
would it? (If specular, phong, etc. defaults are 0)

-sascha

Post a reply to this message

Hi Thorsten,

my scene *is* complete: it does render, resulting in a thin "line" with
color <63,63,63>/255, an approximation of <.25,.25,.25>. As sascha wrote,
my light source is "ambient 1". Not only the border is anti-aliased: try
+R9 and wait many minutes for the pure black background to be rendered.
Of course there is no visible effect on this background, but time is
consumed depending on +R. If this time is not being used for anti-
aliasing: what else does POV-Ray do during this time and why does it
depend on +R?

Still confused ...

   Sputnik

Post a reply to this message

In article <3f0680c9$1@news.povray.org> , sascha 
<sas### [at] userssourceforgenet>  wrote:

> With "ambient 1 diffuse 0" a lightsource wouldn't make much difference,
> would it? (If specular, phong, etc. defaults are 0)

If the light source color is something like rgb 5:

My main point is that without a complete scene it is impossible to say what
is wrong with the scene ... it is up to speculation how the rest of the
scene looks like.

    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

<fr### [at] computermuseumfh-kielde> wrote:

> my scene *is* complete: it does render, resulting in a thin "line" with
> color <63,63,63>/255, an approximation of <.25,.25,.25>. As sascha wrote,
> my light source is "ambient 1". Not only the border is anti-aliased: try
> +R9 and wait many minutes for the pure black background to be rendered.
> Of course there is no visible effect on this background, but time is
> consumed depending on +R. If this time is not being used for anti-
> aliasing: what else does POV-Ray do during this time and why does it
> depend on +R?

I am sure there is a logical explanation for what you are observing, but
checking it to the detail you are looking for, sorry, I don't have that much
free time at the moment.  Something might not be worded too well in the
documentation, and I am sure that the paragraph 5.2.6.4 you referred in your
initial post talks about anti-aliasing method one most of the time.  A few
things definitely were changes over time in the implementation of
anti-aliasing to cover a few features added later (in particular the alpha
channel), and this did require a few small changes in the source code.

> Still confused ...

You are suffering from the "documentation is specification" problem.  The
POV-Ray user documentation is by no means a specification how POV-Ray has to
behave, but it simply outlines how POV-Ray did behave at the time that
section of documentation was written.  Sometimes this does not perfectly
match a decade later ... but note that I am not saying this is the case
here, only that it might be the case here.  You and everybody else are
invited to investigate this by looking at the source code.  Then we can
improve the documentation based on your findings!

Or, in short and German:
Bitte nicht jedes Wort der Dokumentation auf die Goldwaage legen! ;-)

    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

> +AM2

  As far as I know, most of the antialiasing text in the documentation
talks about method 1. Method 2 works a bit differently and it's not very
extensively documented, AFAIK.

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