Hi Timothy,

First, a brief introduction.  I'd describe myself as a moderately 
experienced 3D graphics coder.  I've coded 3D renderers off and on over 
the last 25 years, but not X or OpenGL.  I sat down to learn OpenGL a 
couple of years ago and coded a simple game engine as an exercise.

So now I know just enough about OpenGL to be dangerous.  I know next to 
nothing about logic programming, but I've resolved to cure that 
deficiency.  I hope to pry loose some time for X driver coding over the 
next few months.  Initially somewhat skeptical, I now believe this 
project is going somewhere and deserves support.

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.

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.  The visualization crowd may care a 
little more, but ought to be entirely satisfied with a textured 
triangle approach as above.

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.

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.

[1] No pun intended

Regards,

Daniel
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to