> So far, the message I've been getting about OpenGL lines is "don't bother".
I would at least implement the standard bresenham line in hardware. > However, it concerns me a bit. Say you have a scene which is a > combination of lines and triangles. If I don't accelerate lines, then > they have to be done in software, which sounds simple enough. But > consider the case where a line is in front of some triangles and behind > some. If the all the rasterization of the line is done in software, > what do we do about the Z buffer state? > > For chips that don't accelerate lines and points, how do their drivers > solve this problem? > > I have a crude solution to the antialiased lines which is to render four > overlapping rectangles with alpha of 0.25. But as I say, it's crude, > because you only get four gradations of pixel coverage. > > Another crude solution is to rasterize a set of 6 triangles which are > arranged such that alpha goes to 1 towards the center and towards 0 at > the edges. This would be smoother but would still be a crude approximation. I don't think these approximations are very useful. The goal of smooth lines is to have the alpha represent coverage. (well, OpenGL isn't very specific about smooth lines, but I don't think this would be according to spec.) > Suggestions? You could implement smooth (wide) lines using a polygon, and have smooth polygons done in hardware, using area sampling. Optionally, 1.0 width smooth lines might implemented in hardware seperately from wide lines, e.g. using Gupta-Sproull. --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)
