aa triangle caveat

recently conceived of making the step to opaque 3d over wireframing. found a popular resource that helpfully defined two cases of triangles (an arbitrary definition but any case of two for triangles applied to a cartesian grid is okay) – when y for points is arranged low to high, the median point is to the left or to the right…

equipped with such a definition one is presented with two cases for procedurally approaching the triangle.. now the left and right borders can be easily defined and intermediate pixels rendered.

to aa my triangles i took the slope from each side and computed the number of pixels width that a 1 pixel aa border would occupy (as a float) so that rendering each aa’ed side is not intensive.

the tutorial i followed, after presenting the case for left pointing and right pointing triangles, rendered them in two stages – top corner to middle corner, middle corner to lowest.. seems a sensible approach, one side on the left, one side on the right…

following this topology, one is then presented with four special considerations – rows containing corners overshot the aa from the opposite side. so i had to rewrite my triangle prodecure, and here’s what i did differently:

there are still two cases, for left pointing and right pointing triangles going by the intermediate y coordinate. however, the entire triangle is rendered in one for loop, which uses the float border value at pixel + 0.5 and uses the slope with the current pixel’s x + 0.5 to determine an aa value for each side..

if the aa value is lower than 0, the point is outside of that side.. if it’s greater than 1, it’s inside that side. then clip them all at [0,1]. instead of attempting to save cycles with sneaky crap like dividing the process at the median y point, do the whole thing, compute all three sides, then go aaa * aab * aac

this will work much better than “efficient procedures” that will fuck up if triangle sides et c. are subpixel, or slopes are almost horizontal et c.