What do people think of Texture Anti-Aliasing (glAArg)?

Started by
3 comments, last by Tsus 12 years ago
What are your thoughts on this technique?

http://homepage.mac....ugs/invariance/

I think it's a really cool technique that gets great results. I'm a little surprised by the fact that it seems relevant even today, despite being really old. I think it can be used for some UI or vector-graphics rendering code in OpenGL, where precise and consistent anti-aliasing is a heavy requirement.

I'm also a little worried that it will die off and become unavailable soon, since there is no support for it.

Or am I wrong, and is there a newer modern technique that supersedes glAArg completely, making it useless and no longer necessary?

My question is this: Is glAArg a gem that's worth holding onto and developing further, or is it best to forget about it and use technology/technique X to get the same results?
Advertisement
Antialiasing is not a so simple problem. Probably that feature will be usefull for someone (never directly needed that). But forcing video cards vendors to add that feature will be a hard hit for them (some of them). In last years OpenGL (as well dX) evolved thanks to new chances given by newest hardware. So it is more like Hardware->API Specifications than API Specifications->hardare (just my silly opinion).

Newest vendors (if any) have to follow specifications, but those specifications are made also thanks to specific features old vendors have "invented". (Who is using OpenGL ES for example have to follow ES specifications, but those specifications was made apposite for light devices keeping in mind their limited hardware).

Peace and love, now I understand really what it means! Guardian Angels exist! Thanks!

I just read over the article. It’s no surprise at all that FSAA performance worse, since it is quite a brute force way to anti-alias something. smile.png

A very effective way to anti-alias primitives is to use MSAA (or one of its variants like CSAA). With freeglut it’s enabled with just one line. You can have influence on the sampling rate per pixel and can even alter the coverage mask. It also goes well with alpha2coverage (which once has been used to anti-alias leaves and trunks in the speed tree renderer, if I recall correctly).

If we talk about deferred rendering of scenes with heavy fragment shaders, SRAA and the stuff Andrew Lauritzen did in the tile-based deferred rendering come into play (dynamically increase the sampling rate if edges are present).

If we get back to 2D and UIs, I think, most critical with Texture AA is that it needs texture fetches, which are usually quite expensive (a few hundred cycles in case of a cache-miss). I’m having the feeling that rendering a triangle with MSAA is faster than a textured single-sampled triangle. If the primitives are textured anyway, then Texture AA seems to be nothing more than texturing with mip mapped textures – a thing we always do, not only for anti-aliasing but also to increase performance (due to a better cache coherence).

I can’t say for sure, whether MSAA is always a better choice for smoothing edges of primitives, since I didn’t benchmark both approaches. This should clearly be done to make an informed choice. Though, I have a feeling in my stomach that MSAA might be better. smile.png
But I don't think MSAA achieves the same final result quality, does it? So even if it's faster, it might not be an appropriate replacement.

But I don't think MSAA achieves the same final result quality, does it? So even if it's faster, it might not be an appropriate replacement.

True, it depends on the number of samples. Since Texture AA is pre-computed and can use as many samples as it wants, it will have better quality than let’s say 4xMSAA (or any other dynamic approach, does it?). It would be interesting to see at which number of samples the difference isn’t noticeable anymore.

Still, good to have a fallback solution in case one needs better performance, right? wink.png

This topic is closed to new replies.

Advertisement