<p>This is the same problem as discussed in <a href="https://computergraphics.stackexchange.com/questions/2484/what-are-sample-gaps-during-scan-conversion">What are sample gaps during scan conversion?</a></p>

<p>Briefly, rasterisation - at least with the majority of hardware systems - tests at a single 'infinitesimal' point for each pixel to determine if that pixel is inside a given triangle. </p>

<p>If the sample point lies exactly on an edge, then additional tie-breaking rules, often referred to as "fill rules", come in to play. Typically these will be something equivalent to, say, only consider the edge points on the top/left** edges of a triangle to be "inside".</p>

<p>**Other rules are available ;-)</p>

CC BY-SA 3.0
2016-06-15T11:00:46.270Z
Yeah i was just looking for that answer
joojaa
CC BY-SA 3.0
2016-06-15T15:36:39.593Z
Relevant passage from the Black Book: http://www.jagregory.com/abrash-black-book/#how-do-you-fit-polygons-together
xyz
CC BY-SA 3.0
2016-06-15T16:10:58.480Z
Very many thanks! It sorta kinda makes sense now, and that black book looks like a great resource too
Reuben Scratton
CC BY-SA 3.0
2016-06-15T10:58:46.450Z
2016-06-15T14:44:42.670Z
2016-06-15T14:44:42.670Z
Simon F
<p>Apologies for the following noob question, it's just I can't find a satisfactory answer anywhere...</p>

<p>When I render a simple axis-aligned quad made up of two triangles, I don't understand why there's never any visible artefacts on the diagonal edge where those triangles meet. Some of those pixels must be in both triangles, right? So if my fragshader always emits a partially-transparent color - 50% black say - then shouldn't there be a visible dark diagonal line in the resulting quad?</p>

<p>Obviously it's great that this isn't a real problem that has to be coded around, I just don't understand why it isn't. What GPU magic is it that makes this always work out?</p>

CC BY-SA 4.0
2020-11-16T14:08:35.710Z
I have [discussed](https://mcejp.github.io/2020/11/06/bresenham.html) this issue quite in-depth on my blog. The particular rule that I follow is the same as in [Direct3D 10+](https://docs.microsoft.com/en-us/windows/win32/direct3d11/d3d10-graphics-programming-guide-rasterizer-stage-rules).
Martin Cejp
<opengl><gpu><rasterizer>
Why do adjacent triangles never overlap when rasterized?
Reuben Scratton
# Why do adjacent triangles never overlap when rasterized?

(Asked by: username_0 on 2016-06-15)

Apologies for the following noob question, it's just I can't find a satisfactory answer anywhere...

When I render a simple axis-aligned quad made up of two triangles, I don't understand why there's never any visible artefacts on the diagonal edge where those triangles meet. Some of those pixels must be in both triangles, right? So if my fragshader always emits a partially-transparent color - 50% black say - then shouldn't there be a visible dark diagonal line in the resulting quad?

Obviously it's great that this isn't a real problem that has to be coded around, I just don't understand why it isn't. What GPU magic is it that makes this always work out?

**Tags:** opengl, gpu, rasterizer

> **Comments:**
> **username_1**: I have [discussed](https://mcejp.github.io/2020/11/06/bresenham.html) this issue quite in-depth on my blog. The particular rule that I follow is the same as in [Direct3D 10+](https://docs.microsoft.com/en-us/windows/win32/direct3d11/d3d10-graphics-programming-guide-rasterizer-stage-rules).  

---

## 1 answers

### Answer by username_2 on 2016-06-15. Score: 10 | Accepted answer

This is the same problem as discussed in [What are sample gaps during scan conversion?](https://computergraphics.stackexchange.com/questions/2484/what-are-sample-gaps-during-scan-conversion)

Briefly, rasterisation - at least with the majority of hardware systems - tests at a single 'infinitesimal' point for each pixel to determine if that pixel is inside a given triangle.

If the sample point lies exactly on an edge, then additional tie-breaking rules, often referred to as "fill rules", come in to play. Typically these will be something equivalent to, say, only consider the edge points on the top/left\*\* edges of a triangle to be "inside".

\*\*Other rules are available ;-)

> **Comments:**
> **username_3**: Yeah i was just looking for that answer  
> **username_4**: Relevant passage from the Black Book: http://www.jagregory.com/abrash-black-book/#how-do-you-fit-polygons-together  
> **username_0**: Very many thanks! It sorta kinda makes sense now, and that black book looks like a great resource too  

---

