Full Scene Antialiasing [LONG] (was Re: Antialiasing fonts)

Full Scene Antialiasing [LONG] (was Re: Antialiasing fonts)

Post by Gerard Lanoi » Wed, 24 Nov 1999 04:00:00



Hi -

I've been playing with full-scene antialiasing via the viewport
jittering/accumulation technique lately.  (See the Red Book,
3rd edition, pp451-457, and pp464-465).  I'm getting terrific
results (in visual quality).  It's the speed that I'm concerned
with.

My experience (on an SGI Visual Workstation 320, PIII 500MHz) is that
it is  gosh-awfully s-l-o-w.

I wouldn't recommend using this technique in real-time, but this
would be great for generating antialiased texture-mapped font
textures as described previously.

I'm doing 3, 4, and 8-pass jittering.  The problem is that my
frame rate goes down by *more* than a factor of 3, 4, or 8 when
I turn on this full-scene antialiasing.

I'm using the technique suggested in the Red Book (p452) of doing
a glAccum(GL_LOAD, ...) on the first pass, and glAccum(GL_ACCUM, ...)
on subsequent passes, in an effort to save a little time by omitting
the call to glClear(GL_ACCUM_BUFFER_BIT).

OK, now for some questions:

   1. Due to the slowness I am experiencing, I am guessing that the
      processing inside glAccum() is taking place inside my host CPU
      and not my graphics hardware.  Is that true in general?  (see
      next question)

   2. Are there any OpenGL platforms (either PC graphics boards or
      high-end systems) that support a hardware-accelerated accumulation
      buffer?  Is there such an animal?  What would I look for in
      the wglinfo or glxinfo output to see whether this is available?

   3. What are the platforms that support full-scene antialiasing, aka
      "multisampling"?  (I know of two so far: SGI Onyx2 IR, and Intense3D
      Wildcat 4110.)

   4. In one example, I am rendering a vertically oriented blue line which
      lies exactly in front of a vertically oriented red line.  The result:
      I get a purple line.  Not the way natured intended!  Any ideas on
      getting around this particular side effect?  Or is this just the
      price I have to pay?

   5. I noticed the accanti Red Book example is jittering the modelview
      matrix with calls to glTranslatef().  In my code I am jittering
      the projection matrix by adding deltas to the projection parameters:

          glOrtho(-x-dx, x-dx, -y-dy, y-dy,
                  (m_viewSize - z) / 2.0,
                  (m_viewSize + z) / 2.0f);

          glFrustum(-fNearX-dx, fNearX-dx,
                    -fNearY-dy, fNearY-dy,
                    fNear, fFar);

       Should I really be jittering the modelview matrix instead?

       Compare the way accanti jitters the modelview matrix with
       the way the accpersp Red Book example jitters the projection
       matrix.

       I chose to jitter the projection matrix in my example because
       I want to perform full-scene antialiasing on scenes rendered
       in both Ortho and Perspective mode (my application offers a
       choice to the user).  But if this is killing me in speed, then
       I'll have to go the other route.

Here is a code snippet of my drawing loop...

    if (passes == 0) {
        DrawScene();
    }
    else {
        typedef struct {
            GLdouble x, y;
        } jitter_point_type;

        // From the Red book, 3rd ed., p 464.
        jitter_point_type j3[] = {
            { 0.5033922635,  0.8317967229 },
            { 0.7806016275,  0.2504380877 },
            { 0.2261828938,  0.4131553612 }
        };

        jitter_point_type j4[] = {
            { 0.375,  0.250 },
            { 0.125,  0.750 },
            { 0.875,  0.250 },
            { 0.625,  0.750 }
        };

        static jitter_point_type j8[] = {
            { 0.5625,  0.4375 },
            { 0.0625,  0.9375 },
            { 0.3125,  0.6875 },
            { 0.6875,  0.8125 },
            { 0.8125,  0.1875 },
            { 0.9375,  0.5625 },
            { 0.4375,  0.0625 },
            { 0.1875,  0.3125 }
        };

        // Omit these in favor of doing a glAccum(GL_LOAD, ...) on 1st pass.
        // glClearAccum(0.0, 0.0, 0.0, 0.0);
        // glClear(GL_ACCUM_BUFFER_BIT);

        double jitterScale = 1.0/100.0;

        for (int i=0; i<passes; i++) {
            glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
            double dx;
            double dy;
            if (passes == 3) {
                dx = j3[i].x;
                dy = j3[i].y;
            }
            else if (passes == 4) {
                dx = j4[i].x;
                dy = j4[i].y;
            }
            else if (passes == 8) {
                dx = j8[i].x;
                dy = j8[i].y;
            }
            else {
                dx = 0.0;
                dy = 0.0;
            }
            dx *= jitterScale;
            dy *= jitterScale;
            glMatrixMode(GL_PROJECTION);
            glLoadIdentity();
            ProjectionMatrix(dx, dy);
            glMatrixMode(GL_MODELVIEW);
            DrawScene();

            // It will speed it up a little if
            // you do a load on the first pass.
            if (i == 0) {
                glAccum(GL_LOAD, 1.0f/(GLfloat)passes);
            }
            else {
                glAccum(GL_ACCUM, 1.0f/(GLfloat)passes);
            }
        }
        glAccum(GL_RETURN, 1.0);
        glFlush();

Thanks in advance for any hints or suggestions...

-Gerard
ger...@msi.com

PS: I profiled accanti and accpersp - here are the results.
    Interesting to note that glAccum() doesn't even show up on these
    reports, but that the time spent in accFrustum() in the accpersp
    program does show up (but then only .1 of a %).

Module Statistics for accanti.exe
---------------------------------
    Time in module: 35372.418 millisecond
    Percent of time in module: 100.0%
    Functions in module: 22
    Hits in module: 1284
    Module function coverage: 86.4%

        Func          Func+Child           Hit
        Time   %         Time      %      Count  Function
---------------------------------------------------------
   20529.123  58.0    35345.952  99.9        1 _glutMainLoop@0 (glut32.dll)
   14537.796  41.1    14816.800  41.9       31 _display (accanti.obj)
     142.111   0.4      142.111   0.4      248 _glutSolidTorus@24 (glut32.dll)
      96.665   0.3       96.665   0.3      248 _glutSolidSphere@16 (glut32.dll)
      25.718   0.1       25.718   0.1        1 _glutCreateWindow@4 (glut32.dll)
      20.468   0.1      279.003   0.8      248 _displayObjects (accanti.obj)
      10.366   0.0       10.366   0.0      248 _glutSolidOctahedron@0
(glut32.dll)
       9.393   0.0        9.393   0.0      248 _glutSolidCube@8 (glut32.dll)
       0.465   0.0        0.465   0.0        1 _glutInit@8 (glut32.dll)
       0.272   0.0        0.272   0.0        1 _init (accanti.obj)
       0.030   0.0        0.030   0.0        1 _reshape (accanti.obj)
       0.006   0.0    35372.418 100.0        1 _main (accanti.obj)
       0.002   0.0        0.002   0.0        1 _glutKeyboardFunc@4 (glut32.dll)
       0.002   0.0        0.002   0.0        1 _glutReshapeFunc@4 (glut32.dll)
       0.001   0.0        0.001   0.0        1 _glutDisplayFunc@4 (glut32.dll)
       0.000   0.0        0.000   0.0        1 _glutInitDisplayMode@4
(glut32.dll)
       0.000   0.0        0.000   0.0        1 _glutInitWindowSize@8
(glut32.dll)
       0.000   0.0        0.000   0.0        1 _glutInitWindowPosition@8
(glut32.dll)
       0.000   0.0        0.000   0.0        1 _keyboard (accanti.obj)

Module Statistics for accpersp.exe
----------------------------------
    Time in module: 25039.303 millisecond
    Percent of time in module: 100.0%
    Functions in module: 24
    Hits in module: 1495
    Module function coverage: 87.5%

        Func          Func+Child           Hit
        Time   %         Time      %      Count  Function
---------------------------------------------------------
   12485.732  49.9    25014.714  99.9        1 _glutMainLoop@0 (glut32.dll)
   12284.314  49.1    12528.978  50.0       26 _display (accpersp.obj)
     116.927   0.5      116.927   0.5      208 _glutSolidTorus@24 (glut32.dll)
      79.382   0.3       79.382   0.3      208 _glutSolidSphere@16 (glut32.dll)
      23.635   0.1       23.635   0.1        1 _glutCreateWindow@4 (glut32.dll)
      16.877   0.1      230.435   0.9      208 _displayObjects (accpersp.obj)
      12.674   0.1       12.674   0.1      208 _accFrustum (accpersp.obj)
       9.214   0.0        9.214   0.0      208 _glutSolidOctahedron@0
(glut32.dll)
       8.033   0.0        8.033   0.0      208 _glutSolidCube@8 (glut32.dll)
       1.555   0.0       14.229   0.1      208 _accPerspective (accpersp.obj)
       0.660   0.0        0.660   0.0        1 _glutInit@8 (glut32.dll)
       0.282   0.0        0.282   0.0        1 _init (accpersp.obj)
       0.007   0.0    25039.303 100.0        1 _main (accpersp.obj)
       0.003   0.0        0.003   0.0        1 _reshape (accpersp.obj)
       0.002   0.0        0.002   0.0        1 _glutKeyboardFunc@4 (glut32.dll)
       0.001   0.0        0.001   0.0        1 _glutReshapeFunc@4 (glut32.dll)
       0.001   0.0        0.001   0.0        1 _glutDisplayFunc@4 (glut32.dll)
       0.001   0.0        0.001   0.0        1 _glutInitDisplayMode@4
(glut32.dll)
       0.000   0.0        0.000   0.0        1 _glutInitWindowPosition@8
(glut32.dll)
       0.000   0.0        0.000   0.0        1 _glutInitWindowSize@8
(glut32.dll)
       0.000   0.0        0.000   0.0        1 _keyboard (accpersp.obj)

Paul Martz wrote:
> The idea would be to draw your aliased polygonal characters multiple times
> with a jitter added to the projection matrix, and accumulate each rendering.
> When you then return the accum buffer, the displayed image would be
> antialiased. See the red book program "accanti" which comes with the GLUT
> distribution for an example of using the accumulation buffer to achieve
> full-scene antialiasing.
> --
>    -Paul Martz
>     Hewlett Packard Workstation Systems Lab
>     Remove DONTSPAM to reply

 -disclaimer-
 unless stated otherwise,
...

read more »

 
 
 

Full Scene Antialiasing [LONG] (was Re: Antialiasing fonts)

Post by Paul Mille » Wed, 24 Nov 1999 04:00:00


Quote:> I'm doing 3, 4, and 8-pass jittering.  The problem is that my
> frame rate goes down by *more* than a factor of 3, 4, or 8 when
> I turn on this full-scene antialiasing.

This is true, since the accumulation time is added to the rendering time
of a single pass.

Quote:>    1. Due to the slowness I am experiencing, I am guessing that the
>       processing inside glAccum() is taking place inside my host CPU
>       and not my graphics hardware.  Is that true in general?  (see
>       next question)

Yes. Unless there is hardware accumulation and a very fast pipe to the
buffer.

Quote:>    2. Are there any OpenGL platforms (either PC graphics boards or
>       high-end systems) that support a hardware-accelerated accumulation
>       buffer?  Is there such an animal?  What would I look for in
>       the wglinfo or glxinfo output to see whether this is available?

Yes. The SGI Onyx RE, IR, and IR2 all have hardware accumulation
available. It's nice.

Quote:>    3. What are the platforms that support full-scene antialiasing, aka
>       "multisampling"?  (I know of two so far: SGI Onyx2 IR, and Intense3D
>       Wildcat 4110.)

RE has it as well if you have enough Raster boards. What's nice is the
SGI systems don't have a noticeable penalty when using it. From what
I've heard the Wildcat is 4X slower when it is enabled (which leads me
to believe that the Wildcat is not really doing multisampling, but
rendering at a larger size and scaling down automatically).

Quote:>    4. In one example, I am rendering a vertically oriented blue line which
>       lies exactly in front of a vertically oriented red line.  The result:
>       I get a purple line.  Not the way natured intended!  Any ideas on
>       getting around this particular side effect?  Or is this just the
>       price I have to pay?

Is it in front of the red line spatially or are they drawn at the same
depth? Multisampling should get around this (either per-pixel or the
scaled-down variety).

Quote:>        I chose to jitter the projection matrix in my example because
>        I want to perform full-scene antialiasing on scenes rendered
>        in both Ortho and Perspective mode (my application offers a
>        choice to the user).  But if this is killing me in speed, then
>        I'll have to go the other route.

Just accumulating in software is what is killing you. :-)

--


 
 
 

Full Scene Antialiasing [LONG] (was Re: Antialiasing fonts)

Post by Ross Cunni » Thu, 25 Nov 1999 04:00:00



> Hi -
> I've been playing with full-scene antialiasing via the viewport
> jittering/accumulation technique lately.  (See the Red Book,
> 3rd edition, pp451-457, and pp464-465).  I'm getting terrific
> results (in visual quality).  It's the speed that I'm concerned
> with.
>    1. Due to the slowness I am experiencing, I am guessing that the
>       processing inside glAccum() is taking place inside my host CPU
>       and not my graphics hardware.  Is that true in general?  (see
>       next question)

It depends.  Most cards do glAccum() operations in software.  But see
below.

Quote:>    2. Are there any OpenGL platforms (either PC graphics boards or
>       high-end systems) that support a hardware-accelerated accumulation
>       buffer?  Is there such an animal?  What would I look for in
>       the wglinfo or glxinfo output to see whether this is available?

HP Visualize FX graphics on Windows NT have hardware-accelerated
accumulation buffers as an option when the optional texture memory is
installed.  Other high-end cards may have this as an option as well, and
low-end cards may have things which are close (3DFX's "t-buffer" is
remarkably similar to a limited-pass accumulation buffer).
Unfortunately, there is no standard way for a program to detect whether
HW accumulation is present.  Apps often have two choices to overcome
this issue:

    1. Leave it entirely up to a user-selectable preference option
       whether to enable multipass antialiasing

    2. Run a mini-benchmark during program initialization and see if
       accumulation is "fast enough" to do all the time.  One advantage
       of this technique is that you can decide how many passes you can
       do all the time; you can then render even more passes when the
       animation stops (if that is an option in your application).

Quote:>    4. In one example, I am rendering a vertically oriented blue line which
>       lies exactly in front of a vertically oriented red line.  The result:
>       I get a purple line.  Not the way natured intended!  Any ideas on
>       getting around this particular side effect?  Or is this just the
>       price I have to pay?

It's part of the price you have to pay.  If it's any consolation, I
believe that in actual scenes, this type of artifact should be rare.
Also, notice that in "nature", you get similar effects - that's why
dithering comes close to working (and in fact does work if the dither
cell size is small enough relative to the angular resolution of the
eye).

Quote:>    5. I noticed the accanti Red Book example is jittering the modelview
>       matrix with calls to glTranslatef().  In my code I am jittering
>       the projection matrix by adding deltas to the projection parameters:
>        I chose to jitter the projection matrix in my example because
>        I want to perform full-scene antialiasing on scenes rendered
>        in both Ortho and Perspective mode (my application offers a
>        choice to the user).  But if this is killing me in speed, then
>        I'll have to go the other route.

It shouldn't matter which matrix the jitter is in.  I think what is
killing you is software emulation of accumulation.

Ross Cunniff
Hewlett-Packard Workstation Systems Lab

 
 
 

1. Scene became smaller after using full-scene antialiasing

I tried to use accumulation buffer to do full-scene antialiasing  in my
programme.

I met the problem:
After I used glClearAccum(.0,.0,.0,.0);
the scene generated by opengl was always smaller than the window's client
area.

Can anyone tell me how to resolve the problem?

Thank you for your time

YingTao

2. Reading the MODELVIEW matrix entries

3. Full-scene antialiasing: a new method

4. HELP: RGB to CMYK problems.

5. How to achive perfect (full-scene/edge) antialiasing?

6. Multimedia Degree Programs

7. What's Full Scene Antialiasing?

8. Rendering for compositing

9. Full-Scene Antialiasing

10. TIFF antialiasing without antialiasing?

11. full screen order independent antialiasing ???

12. OpenInventor Scene Antialiasing

13. OpenInventor Scene Antialiasing - followup