# Drawing a border on a 2d polygon with a fragment shader

I have some simple (<20 vertices) polygons rendering flat on a simple xy plain, using GL_TRIANGLES and a flat color, a 2d simulation.

I would like to add a border of variable thickness and a different color to these polygons. I have somthing implemented using the same vertices and glLineWidth/GL_LINE_LOOP, which works, but is another rendering pass and repeats all the vertex transforms.

I think I should be able to do this in the fragment shader using gl_FragCoord and the vertex data and/or tex coords, but I'm not sure, and my naive attempts have been obviously incorrect.

I imagine something like the following.

uniform vec2 scale; // viewport h/w uniform float line_width; uniform vec4 fill_color; uniform vec4 border_color; varying vec4 vertex; // in world coords void main() { if (distance_from_edge(gl_FragCoord, vertex, scale) < line_width) { // we're close to the edge the polygon, so we're the border. gl_FragColor = border_color; } else { gl_FragColor = fill_color; } }

The part I'm trying to figure out is the distance_from_edge function - how can that be calculated? Is using gl_FragCoord the wrong approach - should I be using some kind of texture mapping?

As an experiment I tried converting the vertex to pixel space with the scale, and then calculate the distance between that and gl_FragCoord in pixels, but that give strange results that I didn't really understand. Plus I need the distance to the *edge*, not the vertex, but I'm not sure how to get that.

Any ideas?

EDIT: based on Nicol's response, my question becomes:

Assuming I have a triangle with 3 corner vertices marked as edge vertices, and one vertex in the middle marked as not edge (so rendered with 3 triangles in total), then how do I interpolate in the fragment shader to draw a border of a given thickness? I am assuming I pass the edge flag to the fragment shader, as well as the desired line thickness, and it does some interpolation calculation to figure out the distance between the edge and not edge vertices, and thresholds the color as border/fill as appropriate?

## Answers

All you need are the barycentric coordinates, since you are dealing with triangles. Assign each vertex of the triangle an identity, and then use the hardware's built-in interpolation between the vertex and fragment stages to figure out the relative distance from each of the vertices in your fragment shader.

You can think of the barycentric coordinates for each vertex as the distance from the opposite edge. In the diagram below, vertex P0's opposite edge is e1, and its distance is represented by h1; its barycentric coordinate is <0.0, h1, 0.0>. GPUs may use this coordinate space internally to interpolate vertex attributes for triangles when fragments are generated during rasterization, it makes quick work of weighting per-vertex properties based on location within a triangle.

Below are two tutorials that explain how to do this, typically this is used for rendering a wireframe overlay so you might have better luck searching for that. For your purposes, since this is effectively a specialization of wireframe rendering (with the addition that you want to throw out lines that do not belong to exterior polygon edges), you will need to identify edge vertices and perform additional processing.

For instance, if a vertex is not part of an exterior edge, then you will want to assign it a barycentric coordinate of something like <1,100,0> and the connected vertex <0,100,1> and the interior edge will be ignored (assuming it is an edge opposite the vertex designated <0,1,0>, as seen in the diagram below). The idea is that you never want a point along this edge to interpolate anywhere near 0.0 (or whatever your threshold you use for shading a fragment as part of the border), making it extremely distant from the center of the triangle in the direction of the opposite vertex will solve this.

**Without Geometry Shaders (OpenGL ES friendly):**

Here's a link explaining how to do this, if you are able to modify your vertex data to hold the barycentric coordinates. It has higher storage and pre-processing requirements (in particular, sharing of vertices between adjacent edges may no longer be possible since you need each triangle to consist of three vertices that each have a different input barycentric coordinate - which is why geometry shaders are a desirable solution). However, it will run on a lot more OpenGL ES class hardware than more general solutions that require geometry shaders.

http://codeflow.org/entries/2012/aug/02/easy-wireframe-display-with-barycentric-coordinates/

**With Geometry Shaders ( Not OpenGL ES friendly):**

Alternatively, you can use a geometry shader to compute the barycentric coordinates for each triangle at render-time as seen in this tutorial. Chances are in OpenGL ES you will not have access to geometry shaders, so this can probably be ignored.

http://strattonbrazil.blogspot.com/2011/09/single-pass-wireframe-rendering_10.html http://strattonbrazil.blogspot.com/2011/09/single-pass-wireframe-rendering_11.html

The theoretical basis for this solution can be found here:

http://cgg-journal.com/2008-2/06/index.html