The reason why you need the barycentric extension and can't just make up barycentric coordinates in your vertex shader like: out vec3 vBarycentricCoords;

The reason why you need the barycentric extension and can't just make up barycentric coordinates in your vertex shader like: out vec3 vBarycentricCoords; void main() { ... // wrong vBarycentricCoords = vec3( gl_VertexID % 3 == 0 ? 1.0 : 0.0, gl_VertexID % 3 == 1 ? 1.0 : 0.0, gl_VertexID % 3 == 2 ? 1.0 : 0.0 ); ... } is that one vertex might be shared by arbitrarily many triangles, so there would be no way to guarantee that two vertices don't end up with, say, (1, 0, 0). You would have to split all vertices with valence >= 2 beforehand in the way that game engines do for vertices along sharp edges, which would increase vertex shading load (because you would lose the post-transform cache) and bloat the sizes of the VBO/IBO. I guess you could also use geometry/tessellation shaders to address this problem as well, which would be faster than the pre-split approach but still slower than the technique described in the article (but would be fine if you're just using wireframe as a debugging aid). With the barycentric coordinates extension you don't need any of these hacks and can solve the distance-to-edge problem naturally.