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.
2D lines are easy already.
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.
See my next email for a suggested solution which I THINK might be mathematically correct.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
