PDA

View Full Version : 2D line rendering



Madoc
09-09-2003, 09:44 PM
Rendering lines in 2D (window coordinates) often results in the lines not covering the expected pixels. There are pixels missing at the endpoints, this behaviour also varies from board to board or implementation. Other primitives seem to always give the expected coverage.

I seem to remember that long ago I had seen something suggest that to get exact pixels positions from an orthographic projection which maps to window coordinates you should translate everything by some specific values. Something like:

translate(0.375, 0.375, 0) (could be way off)

Anyone know anything about this? Or some way to correct line rendering?

Relic
09-10-2003, 07:58 AM
Line rendering in OpenGL follows the diamond exit rule.
Pixels are rendered where a line exits the diamond shape centered around the pixel center at (0.5, 0.5) coordinates.
Depending on where your endpoints are and how precise the diamond exit rule is implemented your result may vary.
This includes that rendering a line from A to B is not the same as rendering from B to A!

Other primitives should be arranged so that they truly fill the pixels, don't render along pixel centers.
That is, don't draw a quad from (-0.5, -0.5) to (0.5, 0.5) if you want the pixel at (0,0) filled, instead draw from (0.0, 0.0) to (1.0, 1.0) to hit the pixel center right between the eyes. Always depending on the initial ortho parameters of course!

Adjacent primitives using the same coordinates are guaranteed to always fill without stitches along the edge between them.
T-vertices don't use the same coordinates therefore may show stitch marks depending on rasterizer subpixel precision.

[This message has been edited by Relic (edited 09-10-2003).]

Madoc
09-10-2003, 08:54 AM
Yeah, a google search turned this up. I also found the translation thingie I mentioned which was indeed 0.375. It's purpose was to deal with both polygon and line/point primitives. Don't work with AA though, useless.
Basically, pixel centres for lines and points, pixel boundaries for other primitives. Not sure it deals with the endpoint business though, haven't tested it on more systems yet but it's still a little inconsistant on my FX here.

Thanks