There’s some fun computational geometry in my latest artwork, and in this article I’ll walk through how I take a scramble of disconnected paths and turn them into closed shapes, using half-edges and a planar graph. Work in progress output Work in progress output Work in progress output Agent paths These images begin with a set of “agents” that draw paths. You can think of an agent as a dot that does things (it has “behaviours”). These agents: move around the canvas, leaving a trail behind check whether they’ve run into any existing trails (their own or another agent’s) when they first run into a trail, they go back to the beginning of their journey and move in the opposite direction. when the second end hits something, the path is complete and a new agent is generated somewhere else. Here’s an example with just one agent at a time. The smooth motion of the agents is controlled using Perlin noise, which is essentially a grid of random numbers. To figure out their next move, each agent looks up the number at their current position and uses it to decide which direction to go in next. For example, if the number is 0 they move at an angle of 0°, if the number is 0.25 they move at 90°, 0.5 at 180°, etc. If the values in the field were completely random, the agents would jitter back and forth, constantly changing direction wildly. With Perlin noise, numbers that are close to each other in the grid are similar, so the direction only changes a little bit every step, creating a smooth wandering line. In this animation I’ve drawn a grid of arrows to depict the noise field and you can see the agent following their directions. (As an agent does the second half of its path, it goes backwards along the arrows). After the agents have been drawing paths for a while, the canvas looks something this. Agent paths Right now, what we have is a collection of disconnected paths, one drawn by each agent. They are touching but as far as the computer is concerned, they aren’t connected and these aren’t closed shapes. That means we need to do some work to be able to fill them with colour. There are lots of approaches for this. Some involve drawing the paths out and then looking at the colours of the individual pixels to know if we’re looking at a path or an empty space. You would pick a starting pixel, change it to a fill colour and then move in lines or spreading outwards until you hit pixels that are already filled with the path colour. I had started implementing that a while ago and had a bug that created these super glitchy images, which I love, even though they weren’t what I had planned. Glitchy shape filler Glitchy shape filler For this new project, I wanted to try joining the disconnected edges into fully closed shapes. Luckily there is an established method for this, a planar graph, so I just had to figure it out. Vibe coding? More like vibe front-loading Full disclosure, I had no idea how to do this when I started. I used chatGPT to help me with a first pass at the algorithm and then went through and rewrote all the code so I could understand it and incorporate it into my agents code efficiently. The AI implementation was re-doing a lot of work that had already been done at the agent stage, like finding the intersections. Fun fact: as I recoded it, I was able to bring it down from 444 lines to around 120, before any real attempts at minifying. While the Agents Walk Let’s take a look at a simplified version with just a couple of paths and a bigger distance between the points, so we can see what’s going on. There is a path that goes around the edge of the canvas, enclosing everything. Usually this is right along the edge but I’ve pulled it in a little so it’s visible. Simple version with two wandering paths plus an outer path Let’s zoom in on what’s happening where the two wandering paths intersect. In the images below, we can see that the pink path was created first because the ID numbers of the points are lower. When the blue path came along, it tried to go from point 53 to the location shown with the grey dashed line (first image), which would have been point 54. However, that collides with the existing pink path. Simply stopping at point 53 would create a loose end. Instead, we adjust the position of point 54 to be exactly at the intersection (second image). Blue tried to draw a point but collided with pink New point is moved to be at the intersection While the agents are creating these non-intersecting paths, we’ll save the information that we’ll use later to create the shapes. To create the shapes we’ll need: A collection of points As the Agents create their paths, they also add each point to a shared list. A collection of connections between the points The agents add the connections between the points (e.g. 21-22, 22-23, 23-24) to another shared list. When we put the shapes together, we’ll need to know the angle of each of these connections. We already have this information, because the agent used an angle to know which direction to travel in for each new point. These angles are saved with each connection, so we won’t have to spend time calculating them again. No intersecting connections This is also handled already! As we’ve just seen, an agent never puts down a point that creates an intersection with an existing path, it moves it instead. When we moved point 53, we put it right in the middle of the join between point 22 and 23. In the images below, each join has a different colour and in the second image we can see that the join between 22 and 23 has been split into two, creating a connection between 22-54 and 23-54. Before point 54 Point 54 is placed, splitting the connection between 22 and 23 By the time the agents have completed the paths, we have an list of points and a list of the connections between them, none of which intersect. These things make up a “planar graph". Using the graph Now we’re going to use that planar graph to find all the enclosed shapes in our paths. We want to go from the disconnected paths (on the left below), to the connected shapes (on the right). From paths to shapes The next step is to go through the list of connections and turn each one into two “half-edges”. A connection is made of two points, say 54 and 53, but it’s not just from 54 to 53, it’s also the other way around - from 53 to 54. Each connection is made up of two connections, each one is known as a “half-edge”. In the image below, the original connections are in grey. The half-edges are in yellow and purple pairs. Depiction of half-edges Note that the half-edges actually exist exactly along the paths, I moved them outwards only to visualise them. It doesn’t matter which one is yellow and purple in each pair, there are no “types” of half-edge, they’re just pairs going in opposite directions. One half-edge has the angle we saved with the connection, the other has that angle flipped (we add 180°). Finding the way Pick any half-edge in the image below as a starting point, follow the arrows anti-clockwise and, whenever you reach a junction, take the left-most turn. Eventually you’ll end up back where you started, having travelled around one entire shape. Half-edge paths That’s what we’re going to do to find the shapes, but currently the computer won’t know which half-edge is “left” when we get to a junction, so we need to figure it out. To do this, we prepare by going through each point and ordering its outgoing half-edges by angle. We already have those angles saved with the half-edges, so at this step it’s just a case of putting them in order. Point 54 (below) has 3 outgoing half-edges. 0° is down, so half-edge 111 is at 96°, half-edge 47 is at 116°, half-edge 113 is at 256°. Angles of the outgoing half-edges at point 54 Once we’ve prepared this information for every junction, we work our way through all the half-edges, figuring out where to travel to next. When a point only has two connections, it’s easy, we just follow the path we didn’t come in on! When there’s a junction, we use the angles to figure out the left turn. Looking at the image below, we’re coming into point 54 on half-edge 110. 111 is the twin of 110, so we know we won’t be going out on that one, but we’ll use it to find the left turn. From 111, if we look around the available outgoing half-edges clockwise (which we can do easily because we’ve already put them in order), the first one we come to is the left turn. In this case, when we look clockwise from 111 we come to 113. That’s the left turn and will be our next step. Travelling in to point 54 on half-edge 110 Let’s do another example. Now we’re putting together a different shape and we’re coming into point 54 on half-edge 46. 46’s twin is 47, so we look clockwise from there and find 111, which is the left turn. Travelling in to point 54 on half edge 46 Building Loops Now all that’s left is to go though every half-edge, building paths by following the next steps we’ve figured out. As we go past each half-edge we mark it as “visited” and when we hit a half-edge that’s already been visited, we are back to the beginning of the shape. Then we look for another half-edge that hasn’t been visited again, to start tracing around another shape. Once all the half-edges have been visited, we’ve used all the planar graph information, and we have all our shapes! Depiction of the shapes In this image I’ve adjusted the position of each shape’s path so you can see the separation. The adjacent paths for each shape are in fact tracing the same line. I wanted to show this because it demonstrates that there is one giant shape around the outside. We don’t want that one, so it is deleted simply by looking for the largest shape by area. Now we have 3 shapes that can each be filled with a different colour. Filled shapes Back to complexity That’s cool but it’s much cooler with lots of shapes! Work in progress output Work in progress output Work in progress output In each image, I’m altering the settings within the agents, so that they use Perlin noise in different ways as they create the initial paths. Sometimes different settings are chosen based on the area the agent starts from, sometimes settings are changed when an agent has covered a certain distance, and more. Colours are chosen for each shape based on position. I use a library called Spectral.js to mix together the colour for each shape. Perhaps I’ll do another article about the way colours are placed. Let me know if that’s something you’d be interested in! Work in progress output Work in progress output I hope you enjoyed this article! If you’d like to read more like this, you can sign up to my newsletter below. If you like my work, I have prints and original artworks available in my shop. Feel free to reach out with any questions and let me know what you think! Meaningful Nonsense 02 from £35.00 Handwriting Spiral 2 (8x10") £80.00 Sold Handwriting Spiral 1 (8x8") £80.00

Over the past few weeks, I've been experimenting with painting in watercolours using my AxiDraw plotter. Watercolour is a medium I enjoy painting in (by hand) as a personal hobby, kind of separate from my public art making, so it’s been interesting to combine it with code. I’ve thought about trying this for a while but I was finally spurred on to do it after I visited Licia He’s studio in April. This article is not intended as a tutorial, but more of a scrapbook of what I’ve been trying, the results I’ve created and the mistakes I’ve made (and continue to make). Set up There are a variety of ways to control an AxiDraw plotter. I do it by creating svgs using JavaScript. I open the svg in Inkscape and use the AxiDraw plugin to control the plotter. If you’re wondering how to create an svg in JavaScript - I wrote my own class to do this, after finding that other libraries weren’t working as expected for me. My svg builder is on github and you can feel free to use it. An svg is essentially a series of paths. Usually a plotter moves a pen around those paths. When plotting with watercolour, we also need to create paths to pick up paint, swirl the brush in water and dab the brush on paper towel. Here’s what my set up looks like in real life, with all the equipment taped in place next to the plotter. Watercolour set up in real life I’ve mirrored the real world set up in code. Doing this required a bit of trial and error to make sure things were placed in the right place, but it wasn’t as finicky as I expected it might be. There is a decent margin for error since the areas for the paints, paper and water are relatively large. Watercolour set up in code This output would paint a series of vertical wavy lines on the paper. The blues and greens represent the colours that will be painted, while the thin red line represents the path that will be exported as an svg, for the paintbrush to follow. Notice that there are red circles around the paint areas, lines in the water area, and dabs on the paper. These are all added to the svg in order, so the paint brush will: Swish through a long path in the water Dab the paper towel Circle around one of the paints Swish a short path in the water Paint one vertical line This then repeats for each of the vertical lines. Testing testing Here are the very first watercolour tests I plotted. You can see there are issues with the colour fading out, where the paint has not been refreshed often enough. Or with the results becoming uneven and “scratchy”, where the brush does not have enough water on it. I’ve experimented a lot with the order of actions described above, because picking up more or less water before or after picking up paint makes a difference to the effects created. Brushes In those initial tests I was working with a thin brush, with the bristles cut very short. My thinking was that this might allow for detail but, in fact, the bristles spread outwards, creating visible bristly edges, which I hate the look of. I’ve done some testing with different brushes. Brush 1 is the one I cut short, resulting in a scratchy line. Brush 2 and 3 are similar, but 3 performs ‘better’ - note the defined gap in the centre of the ‘a’ and the correct alignment on the start/end of the circles. A long brush can lead to “inaccurate” shapes, due to the way the bristles are dragged over the paper and become pushed around - you can see what I mean in the 4c photograph below, where the bristles are dragged from the left to the right. This effect can be reduced by carefully setting the height of the brush so that the tip only just touches the paper and by using brushes with firmer bristles. Brush 3’s bristles are much more collected than brush 2’s. Many of these brushes are flat and I placed them diagonally in the plotter. Particularly with brush 3, you can see how this results in thinner lines in the / orientation and thicker ones in the \ orientation, creating a calligraphic effect. The last four tests on the first sheet all use brush 4, but I altered other conditions: 4a - Speed 70%, brush placed with tip just touching paper 4b - Speed 20%, brush placed with tip just touching paper 4c - Speed 20%, brush placed lower down 4d - Speed 20%, brush placed lower down and weight applied The difference between the results of a and b shows that a slower plotter speed can help more paint reach the paper and create clearer lines. The difference in height of the brush in each of these is only a few millimetres but the difference in the results is marked, demonstrating how this process is (happily) difficult to control and filled with chaos introduced by the medium. Brush 4 has been damaged a bit by test 4d, where the brush was weighted down. It’s visible in the photo of the brushes above - the bristles were neater before the tests. I do like the smushy effect of the circle though, it could be interesting to play with that. Brushes 5, 6, and 7 are wider but it’s still possible to write readable words, just at a larger size. The diagonal orientation effect of the diagonal flat brush is also more pronounced here. The first shape on Brush 7 uses the same circular path as all the other brushes - the bristles in contact with the paper just haven’t moved that much. Wider brushes generally lend themselves to smoother edges and no risk of scratchy areas, while thinner brushes are obviously necessary to create detail. I’ve been on the look out for brushes in the shape of brush 3, but shorter and narrower. I also haven’t yet experimented much with brushes of different shapes. This is an ongoing exploration! Smooth lines The first “proper” outputs I created were these Perlin noise adjusted rows of lines. It’s interesting that in the tests of the thinner brushes, the colour often runs out before the end of the word or even the short sine wave. Whereas in these outputs, a slightly wider brush manages to continue the full length of a sheet of A4 paper. Even a small difference to the width of the brush seems to make a big difference to how much water and paint it can hold. Watercolour Words I’ve tried a few different ways of creating typographic pieces, using the handwriting I coded in Javascript (you can read about that here). In this first one I simply repeated the same word in different shades, using a large brush. I particularly like the areas where one word bleeds into its neighbours. I’ve also experimented with using a few words or a short phrase, in different layouts. I love aspects of these, but they don’t quite feel like “finished” pieces, due to the amount of white space. One thing I’m particularly liking is the smudged areas of colour. I dripped water onto the paper by hand as the plotter was working, so that the paint would run. In this video you can see the drips of water on the paper and how the colour spreads and distorts as the brush moves through one of them. I love how this takes advantage of the watercolour medium. In some of these next pieces, I automated this by drawing circles (actually I used the letter ‘o’) in water ahead of the main letters in paint. In this video you can see the ‘o’s drawn in water - showing up as pale purple as the water tray had taken on a good amount of paint by then. As the ‘j’ is drawn, the colour spreads out into the water. These single letter typographic pieces are my favourite watercolour plots I’ve created so far. Few things make me happier than a cloudy gradient. Layering In the past couple of days, I’ve been working towards making the sentence/phrase/word pieces feel more complete by experimenting with layering. I feel like there is something interesting here, but much more refinement is needed. Creating these is a time consuming process so experimentation is slow. I’m working on better integrating the layers, so that the words or other foreground content feel naturally part of a painting. Going forward There are some practical things I need to improve upon - I haven’t been pre-soaking my watercolour paper, which means it warps when it gets wet. This is particularly problematic when trying to set the paintbrush to an exact height above the paper, because the paper is not all the same height. I’m finding the painters’ tape, which I use to create nice clean edges, often lifts up during the process. I’m hoping this may improve when the paper is pre-soaked. I need to get some much smaller brushes to try out. I also have lots of ideas for ongoing exploration! One thing I’ve just started doing but am not ready to share yet (the first test is literally in the plotter as I write this) is using photographs as inputs for representational paintings. Currently this feels like something to try out for fun rather than something I’d want to “really” use the process for - but who knows where it will go. I’m mostly thinking about ways I can make the most of the combination of the exactitude of the robotic method with the chaos of the physical medium. 😍 Enjoyed this article? I’d love it if you could give a boost on Twitter, thanks! ✨ And don’t forget to sign up for my weekly newsletter, filled with updates.

Coding my handwriting in Javascript - how I did it and what I’m doing with it.

My current generative artwork-in-progress includes text, but I don’t want to use a font. In browser based art work, using a “web safe” font could produce inconsistent results, while including a font file would mean a large file size. Additionally, I don’t want a visual element of the project to be something I didn’t create myself. Instead of using a font, I made my own path-based alphabet using p5.js and JavaScript. Fonts, how do they work? I started by looking into what the various points on a font are called. (Mad props to whoever decided that one of the heights in the y-axis of a font should be referred to as the “x” height.) I defined my letters around a central point, mid_x and mid_y. In hindsight it would have been better to work from a bottom left point and I’ll be adjusting this at some point, to help improve my kerning, which is currently inconsistent. Within a Letter class, I defined these key locations like x height, cap height etc, in relation to the font size and the mid point. For example, the full height from base to cap is equal to the font size. From y_mid to y_x is 1/3 of the full height. I also defined some small distances I could adjust a point by, in relation to the height. this.adj_1 = this.h_full * 0.05; this.adj_15 = this.h_full * 0.075; this.adj_2 = this.h_full * 0.1; this.adj_25 = this.h_full * 0.125; this.adj_3 = this.h_full * 0.15; this.adj_35 = this.h_full * 0.175; this.adj_4 = this.h_full * 0.2;   Defining a Letter Each letter is defined by a set of initial paths, of just a few points. Creating these paths was an iterative process of nudging them into the right places. I used a font as a vague guide and also wrote letters on paper to see how they “should” look. The results are a bit of a jaggy scrawl. Don’t worry, there’s more. create_a(){ this.paths = [ [ // stem {x: this.x_left+this.adj_2, y: this.y_x + this.adj_4}, {x: this.x_left+this.adj_3, y: this.y_x + this.adj_1}, {x: this.x_mid+this.adj_2, y: this.y_x}, {x: this.x_right, y: this.y_x+this.adj_2}, {x: this.x_right, y: this.y_base-this.adj_4}, {x: this.x_right+this.adj_1, y: this.y_base}, ], [ // round {x: this.x_right-this.adj_1, y: this.y_mid-this.adj_15}, {x: this.x_mid-this.adj_1, y: this.y_mid-this.adj_1}, {x: this.x_left, y: this.y_mid+this.adj_35}, {x: this.x_mid, y: this.y_base}, {x: this.x_mid+this.adj_2, y: this.y_base-this.adj_1}, {x: this.x_right+this.adj_2, y: this.y_base - this.adj_4}, ] ]; } Curving the paths The next step is to smooth out the paths using Chaikin’s curve algorithm. (Shout out to Aaron Penne for making me aware of this algorithm some time in 2022, I think) Let’s look at a simpler path to see how it works. Chaikin’s algorithm is run recursively and, in each round, we create a new path with the following steps: Copy the first point (the ends stay in place) For the rest of the points before the last point: Add a point 25% of the way to the previous point Add a point 25% of the way to the next point Copy the last point. After one round, we have this. The new path is marked in red. Path after 1 round of Chaikin’s curve algorithm Then we apply the same steps to the resulting path. Here are the results after 2 and 3 rounds. Path after 2 rounds of Chaikin’s curve algorithm Path after 3 rounds of Chaikin’s curve algorithm And here’s the final result. Satisfying. Let’s see what that does to the letters. After 1 round of Chaikin’s curve algorithm After 3 rounds of Chaikin’s curve algorithm Curved paths About 3-4 iterations of the algorithm is enough to get a nice curve at small sizes. If the font is to be used larger (with the points further apart), then more iterations will ensure you don’t get pointy edges. Using Chaikin’s algorithm makes it possible to get smoothly curved paths by only defining a few points. Minimizing Defining the paths in relation to the mid point and cap etc helped me figure out how to draw a letter. For example, I found it easier to think, “the stalk of a b starts at the cap and goes to the base”, rather than “the stalk of a b starts 14.1 pixels above the mid point and ends 7.4 pixels below it”. However, the resulting code was verbose and pretty blergh (as above in the create_a function). To slim it down, I wrote a function which went through each letter and generated new code with everything translated into simple numeric values. // Get string of new code let string = ""; for(let l of this.letters){ string += "create_" + l.letter + "(){\n"; string += " this.ip = [\n"; for(let path of l.ip){ string += " ["; for(let p of path){ string += "{x: " + nf(p.x, 0, 1) + ", y: " + nf(p.y, 0, 1) + "}"; if (path.indexOf(p) != path.length-1) string += ", "; } string += "]"; if (l.ip.indexOf(path) != l.ip.length-1) string += ",\n"; else string += "\n"; } string += " ]\n"; string += "}\n"; } console.log(string)   Here’s the resulting code for the letter a. Much smaller. create_a(){ this.ip = [ [{x: -2.8, y: -3.4}, {x: -1.7, y: -6.8}, {x: 2.3, y: -8.0}, {x: 5.4, y: -5.7}, {x: 5.4, y: 2.9}, {x: 6.6, y: 7.4}], [{x: 4.3, y: -1.7}, {x: -0.9, y: -1.1}, {x: -5.1, y: 3.9}, {x: -2.1, y: 7.4}, {x: 2.3, y: 6.3}, {x: 5.4, y: 2.9}] ] } These numbers are based on a font size of 20 and are simply scaled for different font sizes.   Shapifying the path Here’s the whole alphabet so far. It’s looking pretty natural but it’s also a bit spindly. It’s easy to adjust the stroke weight, but handwritten letters are not usually exactly the same width all the way along the strokes. To enable paths with varied widths, I turned the paths into 2D shapes in an algorithm I call ‘shapify’. To see how it works, here’s that zigzag shape again, after it’s been curved. To create the shapified path, we go along this path and, at each point: Find the angle from that point to the next (for the last point, finds the angle to the point before and flip it 180°) Using Perlin noise, choose the width the path will be at that point. Here I’ve drawn a line at each point of the path, to demonstrate those angles and widths. Notice how each of the lines is a slightly different length and their angles follow the curve of the path. From there it’s easy to see how we can draw a path around the inner path to create our variated width path. At the end of the line, it draws a little loop of points around 180° to create a nice round line cap. I did not know I would be making this weird little wormy guy when I started this article. Side note: My ‘shapify’ algorithm is not at all perfect. When the stroke width is wide, these awkward inner loops appear at tight corners. It’s the same issue I explored in this article. Luckily, in this implementation the whole thing is filled anyway, so it doesn’t matter too much. One last thing I did is to jitter all the points slightly using Perlin noise. This adds another layer of natural feeling to the letters as well as giving them variety. Here’s how the whole alphabet looks: Aesthetic edits Now that the system is set up, it’s possible to play around with all kinds of settings to create different effects. For example, instead of altering the line width with noise, we can do it based on the letter placement. (Thanks to Piter Pasma for the suggestion.) Or we can mess around with higher resolution noise for more jitteryness. What does it weigh My letter class is now 9.7kb. This includes: Path definitions for all letters A-Z in lower and uppercase, and 7 punctuation marks. Letter spacing (although I’m still fine tuning this) Function to resize paths for font size. Function to create the smooth path by calling Chaikin algorithm (but not the algorithm itself, as that’s a function I also use elsewhere) Functions to create and draw NaturalLine objects which handle jittering the path points and shapifying the path etc (but not the NaturalLine class itself, as that’s used all over this project) There are definitely ways I can cut it down more as well. (I am not interested in tips on how to cut down file size at this time, thanks lol.) When I started defining paths, I was a bit worried I was on a fools errand because I pretty much had to define the whole alphabet before I could really test the look of the results in place, but now that I have it on the WIP outputs, the handwritten effect is looking just how I wanted. Enjoyed this article? I’d love if you could give it a boost on Twitter. Thanks!