So it’s been a while since I’ve posted an update, but that’s not to say progress hasn’t been made. Very far from it. Bezzy was due last week, which means I spent all my days (and nights) scrambling to get it done. This has left me with little time to update this blog. I ended up getting everything I wanted done in time, albeit not quite as polished as I would have liked. Still, that’s how software development goes.

So what have I been working on for the past week? Keyframe animation, two Non-Photorealistic Rendering (NPR) fill techniques, and a little tech demo to tie all of this together. I also visited my “friend” Dynamic Tessellation for a bit.

We’ll talk about the first two today. Part two will be posted “soon”.

(read on…)

In my last post, I said I’d talk about how I fixed a rather “fun glitch” which related to fill modes. Just to refresh your memory, it looked a little something like this:

If you read my last post you can probably figure out what’s going on here. The fill geometry I’m rendering is smaller than the path itself. Here’s a screenshot that makes this a bit more obvious:

This is possible because the programmer has the ability to scale the fill and position the fill origin wherever s/he would like. What I need to do is ensure that the entire path is always filled, regardless of the fill parameters. This means that the geometry needs to be big enough to go from the fill origin to every vertex that creates the path.

(read on…)

I’ve taken a break from working on the confusing world of dynamic tessellation to work on the slightly less confusing world of fill modes. While the screenshots I’ve been posting should make it obvious that I already have filling working, it is still mostly prototype code, and therefore is filled with holes, hacks, and fun glitches like this:

We’ll go into how I fixed that in my next post. I want to spend this post talking about how I got fill modes to work in the first place.

Anyone who has done any work in OpenGL will tell you that creating gradient filled shapes is a trivial task. All the programmer has to do is assign colours to each vertex in a triangle and OpenGL will do all the magic colour interpolation for you. Unfortunately, this isn’t good enough for Bezzy. If we can only colour on a per-vertex basis, what happens when a gradient fill is applied to a path where the colour changes between vertices?

For example, let’s say we have a rectangle filled with a red-green-blue linear gradient fill. The rectangle has four vertices, one at every corner. We can colour those vertices red or blue, but since there are no vertices in the middle of the rectangle, we can’t colour anything green.

The obvious solution is to use pixel shaders to do the filling. Bezzy is targeted at computers with fixed-pipeline graphics cards, so I didn’t even consider that solution. Instead, I used a magic little videocard feature called the stencil buffer.

(read on…)

I’ve spent the past couple of days refactoring a tonne of code. That’s the problem with writing prototype/proof of concept code … eventually you need to go back and make sure it all works! With that out of the way (and the code looking pretty spiffy), I focused my attention on dynamic tessellation. I haven’t come up with an optimal solution yet, but I’ve made some good progress.

First, what the heck is tessellation, and why is my approach dynamic? Tessellation is breaking up smooth paths (in our case, Bézier curves) into a number of smaller lines. The more lines we use, the closer the approximation is to the actual curve, and as a result, the smoother the lines appear to be. Videocards are unable to render Bézier curves, they can only render points, lines and triangles. As a result, tessellation is critical to rendering curves on hardware.

Now the “dynamic” bit. This has to do with how we perceive smoothness. Basically, the bigger a curve appears on screen, the more lines are required to make it appear smooth. By scaling the amount of tessellation we use on the curves, we can ensure that we always have smooth looking curves using a minimal amount of lines.

Let’s take a look at the different approaches I took to solving this problem. I used three paths which I will creatively call (from left to right) Path 1, Path 2 and Path 3. The screenshot on the left shows the paths rendered in debug mode. Each line is coloured differently to make the tessellation obvious. The screenshot on the right shows how it would actually appear.

(read on…)

Yesterday I tackled the issue of morphing animation. As you might expect, morphing generates a path that is an interpolation of a source and destination path. My test subjects we’re these two innocent looking paths:

So we’re trying to get the shape on the left to morph into the shape on the right. The first attempt was, errr, “interesting”:

The second attempt was better. But, you know, better is a relative term …

A bit of tinkering later, it worked! And then I went nuts trying out different shapes and stuff. The result:

So that’s what we’ve got in the way of pretty pictures. Technical details below the cut.

(read on…)

Among the computer science courses and random electives I’ve taken this semester is a gem of a course: Computer Graphics, a.k.a. the dreaded CS 488.

The neat part about the course is the final project at the end of the semester: a graphics project of our choosing, absolutely anything we’re interested in. Most of the projects tend to be 3D games, scenes, or raytracers, but I’m trying something a bit different. A hardware-accelerated 2D vector drawing library called Bezzy.

For now, the feature-set looks something like this:

• Render shapes consisting of lines and Bézier curves
• These shapes can optionally be coloured in using solid, linear or radial fill modes
• Arbitrary clipping layers definable by the user
• Keyframe and morphing animation

I’ve made some pretty good progress. Here’s what Bezzy can do now:

Stay tuned for more!