What do people think of Texture Anti-Aliasing (glAArg)?
Members - Reputation: 439
Posted 10 April 2012 - 12:14 PM
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?
Members - Reputation: 290
Posted 10 April 2012 - 01:33 PM
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!
Members - Reputation: 1062
Posted 10 April 2012 - 04:54 PM
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.
Members - Reputation: 1062
Posted 10 April 2012 - 05:48 PM
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.
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.
Still, good to have a fallback solution in case one needs better performance, right?