OpenGL rasterization rules (does it use top-left rule?)

[roamer]

Hi.
Please help me to understand how OpenGL rasterize triangle.
If I draw to triangles with adjacent edges
glBegin(GL_TRIANGLES);
glColor3f(1.0, 1.0, 1.0);
glVertex3f(5, 5, 0);
glVertex3f(0, 5, 0);
glVertex3f(0, 0, 0);
glEnd();
glBegin(GL_TRIANGLES);
glColor3f(0.0, 1.0, 0.0);
glVertex3f(0, 0, 0);
glVertex3f(5, 0, 0);
glVertex3f(5, 5, 0);
glEnd();

it looks like it use top-left rule.
White triangle occupies 10 pixels and green - 15

But when I change positions
glBegin(GL_TRIANGLES);
glColor3f(1.0, 1.0, 1.0);
glVertex3f(0, 5, 0);
glVertex3f(0, 0, 0);
glVertex3f(5, 0, 0);
glEnd();
glBegin(GL_TRIANGLES);
glColor3f(0.0, 1.0, 0.0);
glVertex3f(5, 0, 0);
glVertex3f(5, 5, 0);
glVertex3f(0, 5, 0);
glEnd();

it looks completely different! Why now white triangle occupies 15 pixels not 10?

screenshot:

 

[Simon F]

I haven't looked through your code in detail, but OpenGL is definitely defined to have a consistent fill rule. Don't quote me on this but I don't think it specifically has to be "top left" - any of the other 3 possibilities would be acceptable just as long as a pixel along an edge of abutting triangles belongs to exactly one of those triangles.

 

[Jawed]

Here's your picture:



I used the first of that hosting site's links (on the show codes page) and simply pasted it into the message (I didn't use the "Insert Image" icon).

Here's the specification:

http://www.opengl.org/documentation/specs/version1.1/glspec1.1/node41.html

Since I'm a total OpenGL noob you might want to start here:

http://www.opengl.org/documentation/specs/

and navigate to the version of OpenGL you're using. I've got no idea if the rules vary with specification version (seems ultra-unlikely).

This thread should be useful:

http://forum.beyond3d.com/showthread.php?t=56621

 

[Ethatron]

In case of ambigous depth, the last fragment may win. A common fill-test for 2D-machines was drawing random triangles on screen. If you do this with OpenGL and all triangles on z=0 (for example) you can get the identical result (all triangles will always pop infront) if! the OpenGL-state has a z-compare function with EQUAL configured. In clear: you can say OpenGL if "last-frag-wins" or "old-frag-wins" in case of equal z.

Depending if you draw in back-to-front or front-to-back order you have to choose between LESS / LEQUAL or GREATER / GEQUAL. If you do not have any drawing order, thus random, there is nothing you can do to force deterministic rendering without an A- (linked fragments) or S-Buffer (linked spans).

In case of SSAA enabled you have the chance to get symmetric half-steps for your example above. MSAA will not detect the edge as an edge though.

 

[Simon F]

Hi.
Please help me to understand how OpenGL rasterize triangle.
.....
it looks completely different! Why now white triangle occupies 15 pixels not 10?

screenshot:

There's probably nothing wrong here at all - that behaviour seems perfectly reasonable to me. Tie-breaking fill-rules simply say that if an edge of a triangle falls exactly on a sample point, then you have to include additional conditions to decide if that sample is inside or outside the triangle, which depends on the direction of the edges.

If, on the other hand, you had swapped the order (and not the positions) of the white and green triangles and then got a different results, then that would be worrying.

 

[roamer]

Hi again.Thanks!
I'm working on my own OpenGL implementation. I implemented a triangle rasterization based on barycentric coordinates (OpenGL spec. recommend to use barycentric coordinates to compute candidate pixels to draw). Now my triangle is ok. But this algo use bounding rectangle of the three vertices and looping over this rectangle during computation of candidate pixels. It is not efficent(slow) because we waste time checking pixels out of triangle. Anyone have idea how this algo may be improved?