What is "line AA"?

This is anti-aliasing of drawn lines. This is easier to do than FSAA, and I think all cards used to do it. Starting with the GeForce 256, I think, vendors started disabling it in their consumer cards since it is a feature needed primarily by workstation customers (it's essential for looking at wireframes)--so workstation users would have a reason to pay the premium price for the workstation versions of chipsets.

Drawn lines do show up in games from time to time (Homeworld) so it is nice that ATI is enabling this again.
 
But line AA is only a performance-saving technique. When FSAA is enabled, lines will automatically be anti-aliased.
 
Line AA normally uses completely different AA algorithms than the common super/multi-sampling FSAA methods do. For lines, the preferred method is, for each pixel covered by the line, to compute its coverage and do alpha blending using that coverage value. This generally gives much better AA results for lines than super/multi-sampling does, even with large sample counts. (This method can be used on standalone polygons as well, but produces artifacts if used on two polygons that share an edge.)

For a quick, approximate method to draw antialiased lines, try a google search for "Wu lines".
 
Chalnoth said:
But line AA is only a performance-saving technique. When FSAA is enabled, lines will automatically be anti-aliased.

Dedicated line aa usually anti-aliases lines much more effectively than FSAA, since you can determine the value for pixels the line passes through analytically rather than by sampling.
 
antlers4 said:
Chalnoth said:
Dedicated line aa usually anti-aliases lines much more effectively than FSAA, since you can determine the value for pixels the line passes through analytically rather than by sampling.
Note that analytic-coverage AA would be perfectly possible with polygons as well. Would be relatively easily realized in TBR hardware.
Should offer theorethical image quality improvement over fixed-sample-count AA algorithms.
 
no_way said:
Note that analytic-coverage AA would be perfectly possible with polygons as well. Would be relatively easily realized in TBR hardware.
Should offer theorethical image quality improvement over fixed-sample-count AA algorithms.

Actually, not really. Determining which part it covers is not possible with Wu Antialiasing. Or rather, it's possible by using flags but it pretty much negates the performance benefits...
You could also do some approximations, and if done right the eye might not notice it much. But for high-quality antialiasing, this simply isn't practical AFAIK. Unless someone finds a revolutionary idea for it.


Uttar

EDIT: Just realized you said TBR hardware, sorry for not reading well first. You'd still have to determine samples to check Z, however, no? It could all be done in cache, maybe, but that would significantly increase transistor count. Or did I not quite understand what you said?
 
no_way said:
Note that analytic-coverage AA would be perfectly possible with polygons as well. Would be relatively easily realized in TBR hardware.
Should offer theorethical image quality improvement over fixed-sample-count AA algorithms.

The thing that makes lines easier for analytic coverage is that you aren't worried about Z-occlusion. With polys, as arjan de lumens mentioned above, things get complicated where polygons are adjacent or intersect. A TBR makes this easier to handle, because you know all about the Z occlusion in advance, but in order to keep all the information you need you'd have to allow for any number of polygons possibly affecting a pixel, which kind of defeats one of the advantages of a TBR. That's why I think TBR's have used a sampling approach to FSAA.
 
Prometheus said:
Doesn't 3dlabs P10 use line AA?

I think it uses analytic coverage AA, even for polys. It's got a neat scheme for holding the necessary poly references. I'd have to look back at the article for details.
 
Antialiased lines and polys with analytically determined coverage put into the alpha component ('edge AA') has been available for ages, even my old banshee could do it.

But because it uses alpha blending it's order dependent (back to front :oops: ) and causes artifacts when a pixel is shared by more than two polys. Intersection edges don't get any AA, and worst of all, you need to find the silhouette edges.
Enough reasons to why it has hardly ever been used. IIRC Tomb Raider 1 had the option, but that's the only game I know of.
 
antlers4 said:
Prometheus said:
Doesn't 3dlabs P10 use line AA?

I think it uses analytic coverage AA, even for polys. It's got a neat scheme for holding the necessary poly references. I'd have to look back at the article for details.

I don't remember mention of the P10 using anything other than MSAA or SSAA for polys.
 
3dcgi said:
I don't remember mention of the P10 using anything other than MSAA or SSAA for polys.

My mistake. I was thinking of the Wildcat III, which stores fragment information for each poly on each pixel for SuperScene AA.
 
Line AA?
Pfft. These newfangled raster terminals can't do anything right.
I'll never let go of my Evans&Sutherland.

;) Entropy
 
K.I.L.E.R said:
Line AA is capable of AA'ing alpha textures. Couple line AA with MSAA and you have a perfect AA mode.

Are you sure? Why should line AA help with alpha textures :?: Do you have a link or something to back this claim up? Thanks!
 
K.I.L.E.R said:
Line AA is capable of AA'ing alpha textures. Couple line AA with MSAA and you have a perfect AA mode.

I don't think so. Drawn boundaries from an alpha test generally do not conform to straight lines. That and the order-dependent nature of analytical AA will still apply. I still think developers should depth-sort alpha textures and use alpha blends...
 
Line AA is nothing special at all, except that Nvidia doesn't like GeForce cards to have it enabled, which is pretty silly considering even the Voodoo 1 could, and did do Line AA.
 
Back
Top