Special Needs of Pen Plotters
A small but vibrant community uses NodeBox to drive pen plotters. Many of them post mesmerizing videos of their plotters toiling away on Instagram.
I have recently been engaged in a fascinating thread with florisdejonge about some of the special needs of this community:
Images created in NodeBox by overlaying filled shapes are often not practical or even drawable by a pen plotter. Others, especially resampled paths, are drawable but force the plotter to needlessly raise and lower its pen a jillion times. There is a special art to crafting an image which is not only engaging but also plotter-friendly.
I have not yet succumbed to the lure of the plotter myself so am ignorant of many of these special needs. If I knew more I might be able to craft some plotter-friendly nodes to make things easier. It also occurs to me that pen plotter aficionados probably have many tips to share with each other.
Would any of you pen plotter experts or newbies care to start a discussion? All questions, complaints, and tips are welcome!
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
1 Posted by florisdejonge on 14 Nov, 2020 08:24 AM
I also enjoyed that discussion a lot and the results still prove to be useful (the mask node in particular). This thread had escaped my attention, because I didn’t have time to either visit the forum or playing around in Nodebox in regard to pen plotting.
So, I find the use of Nodebox to generate designs to plot quite interesting and would therefore be happy to contribute. For a start, there are indeed some things to take into account when plotting drawings.
First of all. A plotter draws lines, not shapes in particular. Which means that only the contour of a shape will be drawn. This is especially relevant when making overlapping, combined or occluded shapes. Even though it can look good with a particular colour fill, that’s not the way the plotter will interpret it (similar to Adobe’s Illustrator ‘outline’ view).
Secondly, there is the matter of movement, both up and down and sideways. The more a plotter needs to move, the longer it takes to draw something, but is also adds to the wear and tear of the motors (or even the pens). Therefore you want to join segments of lines that are visually connected to form a continuous movement. In addition, you want to reduce the travel time by efficient ordering the elements.
So, it isn’t so much of a problem of the resampling of paths (let’s say a curve) as long as it is single continuous line. This would not cause the pen to raise and lower, unless the resampling causes the line to break up in different segments. I does make the travel time a bit longer in my experience because it needs to travel to more points, instead of making a fluent motion from one to the other point. I hope this is clear enough.
Support Staff 2 Posted by john on 02 Feb, 2021 05:05 AM
I have a few general questions about plotting I hope those in the plotting community can help me with:
Under what circumstances do you NOT want a single continuous line? If you break a path into multiple consecutive paths, there may be no noticeable difference; I presume the plotter will just keep barreling along until all paths are drawn. But I can imagine that VERY long paths could be problematic.
Can you force a plotter to pause after each continuous path? Separating paths might allow you to pause and swap out pens low on ink for example. You would certainly need separate paths if you need to swap out pen colors or pen thicknesses. As an experienced plotter, do you ever purposefully create breaks by separating long paths into shorter pieces?
To what extent does the sequence of plotting movements matter? Floris already mentioned the desire to reduce unnecessary movements and travel time. But do you also sometimes alter a plotting sequence to create a more dramatic or interesting effect? Or to avoid putting too much ink in one small area at once? Or for any other reason?
In addition to producing an end product, plotting can sometimes be a kind of performance art, especially if you film your plotter in action. To what extent is this a factor when planning a plot?
Can anyone talk about the aesthetics of plot design? I imagine that one goal of plotting is to create works that are distinctive and obviously different from mere printing (e.g. with an inkjet or laser printer). I would think you would want to emphasize the stroke of the pen (or pencil or whatever), or look for images with continuous lines or curves - yes?
I can imagine that the pursuit of simplicity may often play a role in plotter aesthetics. Is that true? If so, how do you go about simplifying a drawing when designing a plot?
What are similarities and differences between plotting and calligraphy?
Thanks in advance for your thoughts.
3 Posted by florisdejonge on 02 Feb, 2021 08:57 PM
These are great questions. I don’t consider my experience and perspective is in any way representative for the plotter community, but I’ll give it a go and try to answer some of them.
I hope this gives some insight in regard to your questions. I did not intend to formulate a definite answer (my opinions change as well), but I find it an interesting discussion to respond to. Also, I am quite curious whether there’s more people that are using Nodebox for plotting.
Support Staff 4 Posted by john on 03 Feb, 2021 03:19 AM
Thanks for these excellent answers. Here are some of my take-aways:
I would think a good plot node should automatically improve efficiency. There are a few simple things that could be done to improve efficiency. For rectangular plots we could automatically reverse the direction of every other row to prevent unnecessary travel time across rows. Discontiguous masks could be automatically sorted and direction reversed as needed to minimize distance between then end of one mask the the start of the next.
I haven't even looked, yet, at your CYMK node; I presume it uses the same algorithm published on the forum. But we could make it so this node has the option of overlaying all four layers OR producing only one at a time. By feeding a frame node into the layer port you could automatically place each layer on frames 1 to 4 and the use the Export Range to export all four SVGs at once.
What other reasons beside color separation might you have for wanting to divide a drawing into separate layers? Different pen widths? Other reasons?
When outputting multiple layers, the plot node should always start from the same place (top left? bottom left?) so overlays will be properly registered. Should we include the registration marks in the output of each layer (as the first thing drawn)? If so, how far outside the margins of the rest of the drawing should the mark be drawn?
When using registration marks do you have to start each layer, watch carefully to see the new mark is aligned, and then quickly stop the plotter if it is not?
A completely different question...
How, in general, do plotters handle dots? I presume they can effortlessly draw circles. But do they have a way of automatically filling in small circles to create dots? Or do you have to do that part yourself by drawing hatching or cross hatching lines inside the circles yourself?
Would it be worthwhile to make a node (or sub-node) to create plottable dots by automatically hatching small circles (or filling the using a spiral or whatever)?
Thanks again. I will follow the links you supplied soon. At some point we can take up some of these ideas, including color separation, in our plot node thread. It would be fun to attempt a four color plot using some evolution of the CYMK plot node with the layer option I described and a registration option.
AND PLEASE, if there are any other NodeBox plotters out there, please join this discussion!
5 Posted by florisdejonge on 06 Feb, 2021 02:56 PM
Thanks for the follow-up.
I would like to go along with the premise that a good plot is one that gets efficiently drawn. It does depend on the artwork what would be the best solution to achieve that though. When broad movements are left to right and top to bottom as in grid-based art, then a zigzag motion is a good solution. I’ve attached such an example to check whether we are talking about the same thing. Is this the general direction you are proposing? I can’t really picture or estimate what such a solution would be if things get more complex, like artwork placed on those grid points, or with circular or organic placing. But its worth exploring. I would consider the calculate-distance-node would come in handy.
The CMYK-node is indeed largely the same as the Plot-node (with my minor additions). It calculates the different CMYK colour values based on RGB, then does the same as earlier: generate points and connect them by lines, but in addition also makes a cutout of alle the lightest values. Which makes the image less dense and results in less lines to draw.
It sounds great to export different color layers in one go. I’ve barely explored Nodebox’ animation capabilities, so I can’t really picture how that would work.
As far as I’m concerned using different pens (being it widths or colors) is the only reason to divide a drawing into separate layers. I can’t think of any other common cases. Perhaps it’s interesting to explore different speed settings for different layers, but that’s not something I’m considering. Another consideration is when plotting something on a larger scale than the working dimensions of the plotter. The Makeblock plotter I am using can plot on around A3 paper size and that’s sufficient for most things. If you want to plot something larger than the working area, the separation of the artwork in different pieces represented as layers could be useful. I could also cut the artwork in two pieces (or more) using Illustrator, I guess. But the times when I needed that are really rare.
That’s correct. The alignment markers are placed the lowest, so they get drawn first. The plotter starts at top left. But that’s determined by the grid-node used in the alignment markers. It just follows the order of the point numbers. Currently I attach this alignment-node at the end of the artwork, but it also could be included in the artwork of each separated color. The preferred length of the markers depends on the size of the artwork. So I just take an intuitive ratio. The same accounts for the outside margins. In addition, you could factor in the dimensions of the paper after cutting the markers off, as a safe margin (this would become relevant when selling or framing the artwork; something I'm not doing right now). Now that I think about it, and after following another discussion about the canvas size here on the forum, it would be useful to get a better grip on plotting on certain paper sizes.
That’s indeed how things are going. I’ve attached a screenshot of the plotter software. Here’s how it goes: I make notes about the size of the artwork and it’s position (I’ve also been keeping notes what settings are best for different pens). After I’ve (the plotter) drawn the first layer, I position the artwork for the next layer and press ‘play’. I walk to the plotter to check whether the alignment markers are drawn on the exact same place. If yes, great. If not, I get back to ‘stop’ the software. Since it draws four markers, and it has to travel between all four, I have enough time to check how things are working out. Quite often, after seeing one or two markers, I know what to change in regard to the position, and am able to stop it before its starting with the artwork. To add extra time (which in some rarer cases could be useful) I would consider adding markers halfway the artwork between the markers at both ends.
The plotter can draw dots. Every point made in Nodebox becomes a dot (the pen just goes up and down without moving). Depending on speed, pen, paper combination these dots sometimes turn out as little lines, but alas. This sometimes causes trouble as well. In some cases Nodebox (or me) adds center points or points from which artwork is positioned. I usually check my artworks in Illustrator by using the Object > Path > Clean Up and delete those stray anchor points.
Larger circles that have to appear as dots should indeed be filled with lines. The people at Evil Mad Scientist do provide an Inkscape Extension to generate hatchfills. See link here. But, I consider it to be faster and easier to do it in Nodebox directly (especially since the Mask-node). There’s also this Stipplegen software which turn images into dots. See link here. Interestingly, it doesn’t generate dots, but spirals, which is a more efficient way to make fills (at least in regard to up and down movements, I sometimes suspect the plotter to faster handle straight lines in comparisons to curves). The software is quite slow, though. I would expect the Image-node to handle a dots-filter based on spirals faster. But than again, the StippleGen first generates Voronoi-cells (and if I am correct Nodebox isn’t able to) and calculates the shortest distance between each path (so-called TSP).
Hopefully this turns out to be helpful in regard to the development of more plotter-nodes.
Support Staff 6 Posted by john on 16 Feb, 2021 06:11 AM
My apologies again for the delay in responding. There is MUCH to digest here. In addition to pondering your excellent insights, I followed some of the links you supplied and was soon overwhelmed with kaleidoscopic possibilities.
I now have a few high-level ideas about how to further evolve plotting in NodeBox:
The end result of all this is that, in addition to image node and a next gen plot node, we could develop a set of interesting mask nodes and a set of interesting pattern-set nodes. You could then mix and match and modify these to create original plots.
I hope the above makes sense. As soon as my schedule allows I will try to create an example with a dynamic mask, an improved plot node, and one or more pattern sets. I will post that in our other thread in the Plot Node thread I started under the Show Your Work section.
I am also still interested in pursuing color separation as a separate node. But I think I will try to tackle the above project first.
One quick question about color layering if you are still with me. I enjoyed the CYMK plot you showed on Instagram. One concern I had with it, though, was that since each color marker is opaque, the order of color plotting is critical and the later colors tend to overwhelm the early colors. My question: is it possible to use watercolor-like pens or brushes that would bleed and create something approximating translucency?
Thanks again for this wonderful collaboration!
Support Staff 7 Posted by john on 17 Feb, 2021 01:00 AM
After outlining that efficiency routine, I realized that doing it in a general purpose way would be similar to the NP Complete Traveling Salesman Problem: difficult in NodeBox and unlikely to scale well enough to handle a large number of paths.
Making the original hatching lines more efficient is easy, though. So for now my approach to better plotter efficiency will be to bake it in to the original masks. The concentric circle mask is already efficient. But the hatching node needs updating.
Accordingly, I just posted an improved version of the hatching node in our Plot
Node discussion under Show Your Work. It works just as before, but zigzags (alternates direction of every other hatching line) to reduce travel time.
From now on anyone doing plotting should use this new v2 version of the hatching node. Floris, if you get a chance, please give it a try and verify that your plotting time is reduced.
8 Posted by florisdejonge on 18 Feb, 2021 07:26 PM
Thank for replying and your update. These are indeed high-levels ideas you’re adding to the conversation. I must admit, English isn’t my first language, so I am not quite sure whether I am grasping all the concepts you’re proposing. If the hatching node is any indication of what an application of such ideas would look like, I am very much interested. I gave this node a quick look, but where in the network is the zigzagmotion implemented? The plot-node looks unchanged, as does the hatching-node, but does the show-order-node also reverse the order of alternating paths? (UPDATE: found it, in the hatching node, was expecting a different solution)
In regard to the CMYK-node, I’ve used this node in some of my recent work on Instagram. I wasn’t that satisfied with the blending of colors either, but I’m using Instagram to keep track and share the process of exploration, more so than posting polished pieces. I was using Posca markers, which are really opague, since the more transparent Staedtler Triplus pens I used earlier for these kind of experiments ran out (people will warn about buying a lot of pens when plotting, and they are right). Other pens are also suitable perhaps, brushes less so (with some exceptions), since you need to keep the ink flow continuous.
As a continuation to this conversation on the Image-node I explored the Plot-node further and made a new version of the CMYK-node, which integrates your earlier improvements (not including those of the second version of hatching-node). I did experience that when using it in higher resolution I could only render the layers separately, because otherwise is becomes quite slow. Which might be caused by my setup to add a wiggle-control.
I also developed some kind of cross-hatch filter as a result your remark on edge detection (this is of course, a really crude application of the term) and breaking the image apart into separate regions first. Which I think is somewhat similar to the solution your proposing to developing patterns with difference densities (which can also be combined in a separate subnetwork). It wouldn't be that hard to reverse every second line, so I'll try to do that next. I think there’s also a great potential in changing the input pattern (or path or geometry) based on luma or rgb color indeed. An ellipse filled with a spiral instead of a dot would be a logical start.
For now, I really want to try to what extend the show-order node increases the speed. I will post back with results.
Support Staff 9 Posted by john on 18 Feb, 2021 10:53 PM
You are making exciting progress.
One clarification: the show_order node does not affect the plotting speed; if anything it would slow it down. I only made it to demonstrate the zigzag motion, which otherwise would be invisible.
So when plotting you should NOT use that node.
I took a quick look at your crosshatch network. I notice you were still using the old hatching node in that version. I assume you will replace it with the new hatching node for your next attempt.
The crosshatch node took forever to render. The reason for this is in the final node of that subnetwork, which uses my mask node. As you know only too well, that mask node is painfully slow.
The mask node is general purpose. The reason it needs make_curve.py is in case the hatching lines passed to it contain curves (e.g. sinewaves). But in this case you are only using line segments. So it would be possible to use no-curve version of the mask node which should run faster.
I once made such a version. I will hunt for it, substitute it in your crosshatch node, and see if that speeds things up.
Your implemation of regions is quite interesting by the way. I will have to study it more closely.
10 Posted by florisdejonge on 20 Feb, 2021 08:05 AM
The result of the test I mentioned and the separate pattern-node I alluded to, can be found in this discussion.
@John: Just a quick question in regard to the separation of color ranges into distinct regions. One might want to vary in the amount of regions per images. Therefore I tried to make subnetworks and feed a range-node (based on an amount of regions for example) into both compare-nodes and switch-nodes, similar to what I often do with the start-index of the slide-node within a subnetwork. But this doesn't seem to work. Maybe I am missing the logic here, but any ideas for a work-around? Hope this question is clear.
Support Staff 11 Posted by john on 20 Feb, 2021 09:38 AM
I did see the other discussion. Your results are about what I expected. There is a lot of churn with the scatter density patterns you are currently using, so the travel time between rows is a relatively small percentage of that - but still worth caring about. Efficiency is something you have to keep chipping away it; the improvements add up over time. We should see a bigger payoff if we can improve the efficiency of the "plotting textures".
I took a quick look at your new node with the five different styles of cross hatching. Nice.
I think I understand your question. I noticed that in the node you sent yesterday you had hardcoded the five different levels. That is not necessary; this should be parameterized to handle any number of levels. I intended to do that myself but have been distracted by other projects.
I can't say why you are running into trouble doing that without seeing your code. Sometimes with subnetworks the problem is that one of the inputs is set to list instead of value or vice versa.
I really like the way you included a posterize_network node to actually show how the different number of levels map to the image. It might be worth exposing this as a separate node, used upstream of the crosshatch node, so that people can get feedback as to how many levels are needed.
I did look for that version of the mask node that doesn't require make_curve and which may be faster, but I need to redo it. For general use handling curves is necessary both for the foreground and the background (e.g. putting lines inside a text character with curves). But at least for cross-hatching inside of regions consisting of joined rectangles that shouldn't be necessary.
I will try to crank out a version of your nodes with parameterized levels and faster masking sometime this weekend.
Support Staff 12 Posted by john on 20 Feb, 2021 10:27 AM
A quick question back at you...
I thought I would start by making a general purpose posterize node that will posterize to N number of levels and output each level as a separate group (region). I think this is what were trying to do.
Looking at your current posterization scheme I noticed a few things about they way you posterized:
I like your end results, but they are hardcoded to exactly five values. To allow N values we would have to do something more generic, like simply dividing the luma range into N equal segments and providing an even sample of grays across the same range.
My question is: do you think a generic, even sample will be OK? Or do we need to let users define unequal luma ranges with custom gray settings for each one to get acceptable results?
Support Staff 13 Posted by john on 20 Feb, 2021 11:27 AM
I think I just answered your question and mine with a general purpose posterize node. I attached it with a description in our separate Plot thread under Share Your Work.
My general purpose posterization is somewhat different than your algorithm, but not wildly different. Since posterize automatically groups the pixels into distinct regions, you should be able to feed it directly into your crosshatch node to generate a plot.
As I said in my comments, we still need to do some work on your crosshatch node to make it more general purpose.
Have a look at the posterize node and see if it solves the problem you were trying to solve. If you look inside, you'll see it's pretty simple.
14 Posted by florisdejonge on 20 Feb, 2021 12:33 PM
Thanks John for providing a general purpose posterize node. Works like a charm! In regard to your comments: my use of the integer node instead of the level node was just a force of habit. Flooring is more correct. I can’t recall my reasons for this irregular range of numbers to determine the separation, it could be aesthetics, or that I decided to change the interval somewhere halfway. It is indeed way more logical to just divide 255 by the amount of separations.
In addition, to use the output of the color separation as input for a mask node though, I always thought one would need to not only make a group of the geometry (ie the pixels), but also make a compound path of it, but this also seems to work. So this cuts out a redudant step.
It’s a great step for experimenting with different fills for areas.
15 Posted by florisdejonge on 13 May, 2021 12:24 PM
I made a subnetwork to simulate the paper size and the width of the pens or markers and to correctly position and scale the artwork before plotting. Thought I should share it here.
Support Staff 16 Posted by john on 13 May, 2021 07:04 PM
You might consider also posting this to the "Plot Node" thread under Show Your Work; that might increase the odds that other plotter people will find this.
Sorry for my recent absence from this discussion. I think your insight about organizing images into regions (using posterize) is step forward that might carry us into new ground. I've been meaning to get back to that and push that idea a little farther. So much to do, so little time!
17 Posted by florisdejonge on 05 Jun, 2021 07:45 AM
Thanks for your reply. I will post the file in the Show Your Work section. Regarding this discussion: indeed there is so much to explore. I regularly will get fascinated by trying to do something, and after a while something else seems more challenging, but I usually eventually will circle back to earlier topics, such as the Image Node.