Screen Anti-aliasing basic question
I understand screen anti-aliasing and even looked at the examples in the Red Book.
But I'm not quite sure how it (typically) fits in to the real world.
Is it pretty much always done? Or is just done if the developer wants just a little
bit more smoother look. Are we talking spackle or dry wall here
I presume it can't hide really bad programming but is more of a light cosmetic improvement?
Also, is it a real drain on resources or is it insignificant compared to the overall openGL work?
But I'm not quite sure how it (typically) fits in to the real world.
Is it pretty much always done? Or is just done if the developer wants just a little
bit more smoother look. Are we talking spackle or dry wall here

I presume it can't hide really bad programming but is more of a light cosmetic improvement?
Also, is it a real drain on resources or is it insignificant compared to the overall openGL work?
FSAA is very expensive, and typically only ever enabled at the user's request, and even then, only a couple of years after the game's released when the hardware has caught up.
Ok, this sounds famaliar. But looking at various anti-aliasing procedures in
the RedBook and on the web, the algorithms don't look all that
terrible. For instance, below is something I dredged up. At a glance, this function
doesn't look all that expensive. Or is it expensive because you are messing
with each pixel/texel and using the accumulation buffer for every rendering cycle?
Seems this functionality could be migrated to dedicated hardware. And with Moore's law wouldn't this be henceforth dirt cheap?
the RedBook and on the web, the algorithms don't look all that
terrible. For instance, below is something I dredged up. At a glance, this function
doesn't look all that expensive. Or is it expensive because you are messing
with each pixel/texel and using the accumulation buffer for every rendering cycle?
Seems this functionality could be migrated to dedicated hardware. And with Moore's law wouldn't this be henceforth dirt cheap?
Quote:void display(void)
{
GLint viewport[4];
int jitter;
glGetIntegerv (GL_VIEWPORT, viewport);
glClear(GL_ACCUM_BUFFER_BIT);
for (jitter = 0; jitter < ACSIZE; jitter++) {
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glPushMatrix ();
/* Note that 4.5 is the distance in world space between
* left and right and bottom and top.
* This formula converts fractional pixel movement to
* world coordinates.
*/
glTranslatef (j8[jitter].x*4.5/viewport[2],
j8[jitter].y*4.5/viewport[3], 0.0);
displayObjects ();
glPopMatrix ();
glAccum(GL_ACCUM, 1.0/ACSIZE);
}
glAccum (GL_RETURN, 1.0);
glFlush();
}
That would most definitely not be dirt cheap. It would actually be the most expensive way to do it. You're redrawing the scene many times, which adds up very, very quickly. The least expensive is multisample. (you must enable it in your OpenGL context, then run glEnable(GL_MULTISAMPLE)) Even then, it can cause major framerate drops if you reach the limits of your video card.
Rendering your entire scene ACSIZE times with accumulation is *not* a good way to do antialiasing. It will be *horrifically* slow. As akb825 says, FSAA (aka GL_ARB_multisample) is the only sane way to do antialiasing. Even then, it's slow.
The most appropriate antialiasing method depends on your content.
FSAA works with generic 3D scenes. If your content is 2D or constrained to certain views, there are much cheaper ways to antialias. Look at the fonts in the OS X menu bar. Nice antialiasing! No FSAA.
FSAA works with generic 3D scenes. If your content is 2D or constrained to certain views, there are much cheaper ways to antialias. Look at the fonts in the OS X menu bar. Nice antialiasing! No FSAA.
Haven't even come across the terms MULTISAMPLE/GL_ARB_multisample yet in
my researching of anti-aliasing. The Red Book introduces anti-aliasing matter of factly and even other online antialising discussions I've read have never so much as mentioned this huge performance hit.
That's what I like about this site; Real world experience. Say, I lost my link to the above
code snippet. I take it that as ACSIZE grows, the aliasing becomes less and less.
Just for argument's sake, would an ACSIZE = 2 be acceptable for performance, or is this algorithm just for educational enlightment.
my researching of anti-aliasing. The Red Book introduces anti-aliasing matter of factly and even other online antialising discussions I've read have never so much as mentioned this huge performance hit.
That's what I like about this site; Real world experience. Say, I lost my link to the above
code snippet. I take it that as ACSIZE grows, the aliasing becomes less and less.
Just for argument's sake, would an ACSIZE = 2 be acceptable for performance, or is this algorithm just for educational enlightment.
I'd treat it as "historical interest only".
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| basic C++ <iostream> question | WhatMeWorry | 3 | 2,841 |
Jun 18, 2006 06:22 PM Last Post: WhatMeWorry |
|

