Smooth, efficient, perfect curves



there was a reply to one of my posts on the old forum and I’ve decided to reply on the new forums instead. It’s about rendering thick lines, a topic that sounds like “didn’t we solve this in the 60’s?” - but is surprisingly hard to pull off if you care about a) the looks and b) performance.

The old post described a way to draw long line strips without the little gaps between the individual segments. OpenGL by default doesn’t do a great job when rendering lines with a thickness > 1, so you have to come up with your own solution. I won’t repeat what I came up with, you can find a full discussion in the old post.

However, recently I was doing a project where I had to draw hundreds, maybe even thousands of quadratic curves per frame. The designers wanted thick (5 pixel) curves, anti-aliased of course, with a nice color gradient from start to end point and an adjustable curvature.

The solution I arrived at is based on this ShaderToy sample:

It calculates a distance to the curve for each pixel and renders a perfectly anti-aliased quadratic curve. It suffers from a few artifacts (e.g. it can’t handle straight lines) and can be optimized a bit more, but it was a good start. My first implementation used simple quads the size of the curve’s bounding box, but that was horribly slow. The calculations don’t come cheap, so you want to minimize the number of affected pixels as much as possible.

Next thing I did was calculating a simple mesh on the CPU for each curve, just so I could experiment with different options. I would then later translate this into a GPU-based solution. I found that it’s sufficient to subdivide the curve into roughly 40 segments (even for strongly bent curves) by calculating the position for:
t = 0.0, t = 0.025,t = 0.050t = 1.0
, then taking the normal of the tangent in that point and extending it outward. The wire frame then looks like this:

As you can see, this reduces the number of affected pixels drastically. It was already much faster to draw, but only if the total number of curves was low. Drawing lots of curves made me CPU bound and the frame rate dropped. So, GPU to the rescue.

I constructed a simple VboMesh, containing 80 vertices (39 segments in total). Their positions are completely irrelevant, for we will calculate them in the vertex shader. Instead, I stored the following information in the vertex:

 x = t0; // the "t" for this position
 y = t1; // the "t" for the next position on the curve (poor man's tangent)
 z = side; // either a 1 or a -1
 w = offset; // used to extend the mesh to accomodate for rounded end points 

To render all the curves, I use instanced rendering. The instance buffer contains the data for each curve:

 ci::vec2 p0;    // start point in window coordinates
 ci::vec2 p1;    // control point in window coordinates
 ci::vec2 p2;    // end point in window coordinates
 float    t_min; // range: we can animate the curve by 
 float    t_max; //        only drawing a portion of it
 ci::vec4 col0;  // start color
 ci::vec4 col1;  // end color

The vertex shader then simply calculates the position of each vertex based on this data.

    // Evaluate quadratic curve.
    vec2 a = evalQuadratic( p0, p1, p2, t0 );
    vec2 b = evalQuadratic( p0, p1, p2, ( t1 < 0.0 ) ? 1.0 - t1 : t1 );
    if( t1 < 0.0 )
        b = a + ( a - b );

    // Calculate normal.
    vec2 v = 2.0 * uThickness * normalize( b - a ) * sign( t1 );
    vec2 n = vec2( -v.y, v.x );

    vertPosition = side * n + offset * v + a;

The fragment shader is very similar to the ShaderToy sample, just a bit more optimized, cleaned up and with fewer artifacts (as in: none).

The end result looks like this:

We can endlessly zoom in on the curves and they remain perfect. Thickness can be adjusted as well, even to values like 30 pixels or more. Rendering 2048 long curves on a 10800x3840 screen takes less than 0.5ms in total, including uploading the instance data from the CPU.

Hopefully this answers your question, Caleb.



Yes! Thank-you for such a detailed explanation. I think that is something I could really work with if not in my current application it is a beautiful solution for future ones.

Could you help me understand quadratic curves a bit more as I am not sure this implementation works in my scenario owing to the way my lines are formed.

To simplify my scenario lets say I wanted to draw a continuous but fading trail behind the users finger. The finger can move with any speed in any direction even doubling back on itself. To draw the line all I have is the current frame position of the finger, the position the finger was in during the last frame, and the position of the finger in the frame before that. As you can imagine this is a queue type scenario where next frame some data will be lost from a few frames ago and be replaced with the new position.

Can I still apply this solution since it involves quadratic curves? The line needs to match each point exactly.



what you’re looking for is called a Ribbon or a Trail. Those can relatively easily be drawn using a triangle strip.

Create a vertex buffer std::deque<ci::vec2>>, which is empty at the start. In the first frame, you store the current position in a member variable. Every next frame, you check if the cursor has moved far enough from the initial position. If so, calculate a normal like so:

auto v = glm::normalize( current_position - previous_position );
auto n = vec2( -v.y, v.x );

, then add 2 vertices to your buffer:

vertices.push_back( current_position + thickness * n );
vertices.push_back( current_position - thickness * n );

, but before you do that you check if the buffer is full and remove the first two vertices if it is:

while( vertices.size() >= 100 ) {

Then set the initial position to the current position to get ready for the next frame. Finally, a quick and dirty way to render the ribbon is to use the built-in functions to render the triangle strip:

if( vertices.size() >= 4 ) {
    gl::begin( GL_TRIANGLE_STRIP );
    for( auto &vertex : vertices )
        gl::vertex( vertex );

, but for better performance and more options I’d recommend creating a gl::Batch or gl::VboMesh with a fixed number of vertices, then update the vertex positions by mapping its vertex buffer in combination with a call to:

batch->draw( first, count ).

See this post for even more info.

Quadratic curves as described in this thread are just simple curves with 2 end points and a control point and are not suited to render wiggly lines.