Algorithmic Plotter Art by Jupiter Jayna

Technical Discussion

Equipment

Like many, in the recent resurgence of interest in plotting, the tool of choice is the AxiDraw and in particular the SE/A3. The API is very good, as is the CLI it ships with, and enables full programmatic control. Furthermore on the occasion I've had a question the response from Evil Mad Scientist has always been helpful.

Having had something of a crash course in artists' materials plotting directly onto primed board is my preference. As opposed to paper or canvas, something like gessobord gives a superior finish when using acrylic paint. It's also more forgiving if the surface the plotter is on isn't perfectly flat.

In terms of paint look no further than the Molotow Acrylic Paint Markers. Real paint that doesn't require an occasional change of clothes coupled with predictable flow. Initially prototyping was done with Winsor & Newton Pigment Markers which are excellent in their own right but didn't produce the finished effect I so lusted after.

Language Choice

Many other programmers producing algorithmic art I've come across use Processing either directly or via a wrapper library. Having had some experience with it when developing the Newton Virus it didn't seem the right fit or perhaps more truthfully: it isn't something I wanted to invest time in learning. Snobbery, perhaps.

Given that we're dealing with — ultimately — lines, or vectors to be more specific, something that can translate a series of vectors into SVG parlance is what is required to get the output of the algorithm onto a board in acrylic paint.

To that end Lisp, Clojure, or something functional seemed to be the order of the day. However for now, Python suffices with matplotlib used as a shim-layer to get from vertices to SVG. It was and continues to be the path of least resistance if not quite as intellectually satisfying as I might have hoped.

In fact, now I've produced a couple of pieces, it's fairly obvious I could replace matplotlib with a relatively simple output layer given everything, so far at least, has been expressed as as a series of lines which is about as basic as SVG gets. Even if you were to use a circle primitive you'd have to describe that fill as a series of lines.

As an aside the title of my first work is Newer Isn't Always Better. The reason being, believe it or not, I originally intended to implement all of this in Logo and Turtle Graphics furthermore on a BBC Micro thus proving it could have all been done in 1982¹. Perhaps when I tire of producing somewhat naïve paintings I'll move into installation art instead.

Programming Workflow

The environment and workflow is fairly typical. It's described as a Dockerfile, coupled with some Emacs chicanery, and finally an auto-refreshing browser window to display the SVG output: it's in the spirit of a REPL environment if not the embodiment.

In fact to an extent, a piece can be produced end-to-end without ever leaving Emacs, I know there are fetishists out there who will not so secretly be pleased by that.

The only minor annoyance, and it is indeed minor, is that the Docker runtime on Mac (or more specifically the hypervisor) is oblivious to USB devices and hence the AxiDraw itself can't be controlled from within it. Well, I could if I switched to using docker-machine. This means one has to go to the bother of hand-cranking the drivers onto, in my case, the Mac itself. It could be worse I suppose.

Hatching (or flood-filling polygons)

When explaining the process behind the paintings it's how much effort goes into filling the shapes with paint that surprises innocent bystanders. Most people are so used to a flood-fill in Photoshop or its ilk they've never stopped to think about how it might be implemented, algorithmically speaking. And while AxiDraw does provide some helper functions for this, adding a fill="purple" attribute to a SVG shape isn't going to cut it.

Tangentially I think that's borne out by a lot of the plotter art that is produced of late; it has a tendency to be line art and so much so it's implicit the work has been produced by a plotter and not by hand².

The AxiDraw supplied extension to Inkscape is more than two thousand lines of fiendishly clever code that turns elements like circles, rectangles, and polygons into a series of vertices and projects lines through the bounding box. It then works out where these lines intersect with the original shape and clips them accordingly. Something of a simplification but you get the idea.

Initially having tried it a few times the extra step to hatch the SVG output in InkScape stuck in the craw sufficiently that I implemented a very crude version of the aforementioned hatching technique myself. It was also many lines of code and while on screen it looked great in acrylic paint it looked like, well, it looked like it had been hatched by someone who had no consideration for ink bleed or brush size nor falling perceptibly outside the lines. Finally and most worryingly they didn't care if the paint faded or ran out mid-stroke: most disappointing.

And — again — withstanding all that, it looked too obviously plotted.

How I Learned to Stop Worrying and Love Clipper

Someone doubtless has already figured this out but when I was looking for a better solution my DuckDuckGo-fu wasn't good enough.

Conceptually it struck me a much easier way to fill a polygon is to draw the same polygon again, but slightly smaller, and repeat at intervals slightly smaller than the width of the brush to ensure no gaps.

In steps Clipper which again is another devilishly clever library that amongst other things can perform polygon offsetting. That is to say take a set of vertices and return another set of slightly smaller vertices. Pop it in a loop and hey presto: a filled polygon with some distinct advantages over one that has been linearly hatched.

First and foremost: there's little risk of the ink bleeding over the edge of the outer polygon or conversley a gap between the hatch line and the outer polygon. The polygons being plotted are concentric and ever decreasing in area.

Secondly the plotter doesn't have to change direction as much and ostensibly this produces flatter and more even fills particularly when using acrylic paint.

Finally it's trivially easy to connect the polygons which means the entire fill can be performed with no pen up or pen down movement which reduces unsightly blotches that can occur when the pen first comes in contact with the surface. Pigment can vary in viscosity and opacity and the effect can be more pronounced depending on the colour.

Technically to achieve no pen up or pen down you do inevitably retrace small areas albeit in a different direction. Despite this, offsetting has proved a far superior technique and algorithmically simpler to implement.

How To Paint, Not Print

It wasn't obvious to me at the outset the direction in which this would go. Initially, when the AxiDraw was originally purchased, I thought the production of intricate lines would be the primary focus. Instead it's filled polygons and how to transfer them from screen to physical media that is seemingly lesser explored and therefore of more interest.

On screen or giclee printed one doesn't have to worry about painting over the same area and accidentally picking up the paint that was just put down. Or how the various different pigments vary in consistency. Or minimising pen-up and pen-down to reduce visible sploges. There's a suprising amount of scope for innovation if you like your fine art to have both paint and brush strokes.

To solve the problem of picking up paint that had only gone down moments before and was still wet I briefly considered using masking. Any portion of a polygon that was obscured would simply not be plotted; again an obvious technique on screen or in print but noticable when done in paint: the brush strokes, if I can call them that, confessed all.

Then I was quite convinced that unioning the polygons that intersected on the same layer was the way to go: and it wasn't until I wrote the above that I realised that the brush strokes mattered more, to me at least. Two or more triangles for example would become an irregular polygon. These look noticeably different when hatched.

Instead it transpires that patience is the answer. Each colour is plotted as a single layer in a single run. Rather, for colours where there are overlaps, the polygons are separated into additional layers. This is an easy way to create a delay — giving the paint time to dry — without sacrificing the brush strokes and the overall aesthetic.

Board Positioning Techniques

One of the more frustrating aspects, the algorithms themselves withstanding, is positioning the board in relation to the plotter. A millimetre out in any direction can be noticeable, especially when dealing with regular geometric shapes. The piece Towards The Light, Then Back Again was particularly unforgiving since any variance was very visible against the white margin.

It's fairly obvious making a jig to hold the board parallel to the plotter at a fixed distance is a workable solution. Alas, it's still on the to-do list.

At the outset my intention was to produce much larger works and simply move the board around plotting an A3 sized section each time. Perhaps predictably I gave up in disgust: getting the registration perfect was infuriatingly difficult. If a polygon saddled two sections the transition was obvious even with the smallest margin of error.

It transpires after enquiring that Evil Mad Scientist will manufacture larger plotters to order: it's a problem I'm happy not to solve.

¹ It could have of course been done, and was done as far back as the sixties

² Patently that is no slur: there are numerous astonishingly beautiful examples of line art to aspire to produce

³ Apologies for the florid language, Paul

Last updated: 20^th February 2020 — as the work develops this treatise will be updated

Algorithmic Plotter Art by Jupiter Jayna

Newer Isn't Always Better

Towards The Light, Then Back Again