[...] > On Wednesday Jan 19 January 2005 09:29:00 PST you wrote: > > What we want to do is compute coverate and turn it into alpha. Well, > > let's think about this for a moment. Any pixel that aligns exactly > > with the center of the line should have alpha of 1.0. Any pixel > > completely off the line should have alpha of 0, and any pixel which > > lies on the edge of the line should have alpha of 0.5. Why not draw > > a polygon which varies alpha from 1.0 at the center to 0.0 at the > > line width away from the center? > > This approach should correspond nicely to GL_LINE_SMOOTH_HINT = > GL_FASTEST. A texture based approach along the lines[1] of: > > http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html > > should work for GL_NICEST. In either case, I presume that all aaline > (and aapoly) handling will be off-card.
If the card were only to be used for 3d rendering, then I would agree. However, in order to be able to draw accelerated lines and paths (polygons) in 2d, a hardware implementation of smooth lines/polygons would be very useful. And really, such AA lines/edges aren't that hard to implement, even in hardware (Gupta-Sproull). You need to draw four triangles (at least) to render a antialiased single-width line---that's a lot more edges than a single Bresenham line with a LUT for antialising. > Games don't care at all about anti-aliased primitives, they only want > full screen anti-aliasing, so devoting a lot of resources to these > primitives is hard to justify. There's more than just games... > The visualization crowd may care a > little more, but ought to be entirely satisfied with a textured > triangle approach as above. Maybe. I prefer the rasterizer handling smooth lines/polygons---that is where it belongs, logically. > A somewhat related topic: Bresenham line drawing should be on-card > because users expect huge wireframes to render really fast and they > expect to see that Bresenham look - no gaps like you'd get by > substituting thin rectangles. Single solid color is the common case, > which is worth optimizing for, i.e., no color interpolation. Jaggy > lines are already so ugly that perspective interpolation is a waste of > effort. Z-buffered and non-Zbuffered lines are about equally common > I'd guess, the latter possibly being a special case of the former. > Whew, lots of work for just this one stupid little feature. I think you'd probably want Bresenham with color interpolation, not just flatshaded. You'd probably be using Bresenham for polygon edges too, so maybe this isn't too hard to implement in hardware. > On the other hand, it would be ok to leave non-aa lines completely out > of the initial release and always use aalines, so everything about > lines gets punted to the driver. Aliased Bresenham lines are very important for normal 2d drawing. OpenGL is not only for 3d and if eventually all applications will use OpenGL for all rendering then it is important to have decent implementations of primitives that are important for typical 2d rendering. --ms _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
