Home → General Discussion →

Special Needs of Pen Plotters

• Edit

john

27 Jul, 2020 05:49 AM

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:

http://support.nodebox.net/discussions/nodebox-2-3/6251-delete-points

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!

John

1. 1 Posted by florisdejonge on 14 Nov, 2020 08:24 AM

   

   John,
   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.

   Floris

   • Edit

2. 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.

   John

   • Edit

3. 3 Posted by florisdejonge on 02 Feb, 2021 08:57 PM

   

   Hi John,

   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.

   • The extent to which the generated artwork consists of continuous lines (or a single line for that matter) is dependent on aesthetic preference and time, I guess. The plotter will indeed just draw along: it’s tireless of course. But there are reasons why I don’t want my plots taking too long: the machine is noisy and I don’t want it on during the night, the longer it’s taking, the risk of the software crashing increases, also the computer might want to update, and the pens might give out, etc. In addition, you can experiment more if the drawing takes a reasonable amount of time. Therefore, decreasing the travel time (the time the plotter moves with the pen up) is a feasible challenge. There’s a plugin for Inkscape to reorder the paths in a more efficient way (which I don't use very often). So, I only order paths to increase efficiency. In addition to the travel time, the amount of lines also determines the time to make a plot. So it could be a consideration to make the most impact with an image with as little lines as possible.
   • I was adamant about joining paths in (I think) our discussion on the use of the mask node). I’ve attached a quick example of what I meant (because I find it hard to explain clearly in words). Left in the file called ‘discontuouspath’ is a path consisting of a single line. On the right are the same lines, but broken apart, which would cause the pen to move up and down (and therefore wearing out the stepper motor unnecessarily).
   • In theory I can pause the plotter after finishing, but I would have to pay attention to the plotter and pause the software manually on the right time. There is no functionality to plan when the plotter ought to pause. But I am using the Mdraw software from Makeblock, while people also write their own, or use Inkscape to control the Axidraw-plotter.
   • So when I am making something in Nodebox with different colors I separate them in Adobe Illustrator in different layers and export those as svg-files. To align the layers of the artwork you need the position the pens perfectly on the same spot, since there’s always slight differences in the height with which every pen is lifted and therefore in the position it lands on the paper (I am applying suggestions derived from dirtalleydesign. I made a small network to generate these alignment markers (see attached example). The software starts drawing the parts from back/bottom to front/top and the alignment markers ought to be drawn first, so the plotter can be stopped and the paper or pen be realigned
   • It’s fun to watch plotters drawing (and some find the sounds soothing). Some go out of their way to capture this. The comparison to a performance is quite interesting, but I would consider most recordings an attempt to give some insight in the craft and in the process (at least that would be my main motive).
   • There’s a lot to be said about aesthetics, but where to begin? In principle the aesthetic of plotting seems to be dominated by lines, but there’s a lot of experimentation going on with making colored areas, using paint, combining techniques, and engraving. In regard to the pictures itself (what is represented) things vary as well, there’s quirky illustrations, redrawings of photographs, and lots of maths-infused art. I suppose because a background in science or programming is necessary to write the code and to control the machines. Looking at art history the aesthetic seems to have its roots in Conceptual Art, Op Art, Minimalism, Post-painterly Abstraction and the like.
   • To conclude, there’s a lot of great information on plotting on https://drawingbots.net/. It’s of course a shame Nodebox isn’t on the list of svg generators (even though I did point it out once to the administrator). But it also gives some insight on what people are drawing with plotters. I personally like the way the physical aspect of an actual pen (including calligraphy) on actual paper can breathe life in what sometimes can seem clinical technical computer generated images.

   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.

   Floris

   • discontinuouspath.ndbx.zip 1.15 KB
   • Screenshot_2021-02-02_at_20.35.25.png 258 KB
   • alignmarkers_02022021.ndbx.zip 1.75 KB
   • Screenshot_2021-02-02_at_21.44.08.png 233 KB
   • Edit

4. Support Staff 4 Posted by john on 03 Feb, 2021 03:19 AM

   

   Floris,

   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?

     • If so, would we need some mechanism to guarantee a pause between the mark and the rest of the drawing?
     • If so, what would be the best way to do this? (I could imagine drawing a second registration opposite the first; the travel time to second mark and back might be enough to stop the plotter in time.) Or is there some other way to do this?

   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!

   John

   • Edit

5. 5 Posted by florisdejonge on 06 Feb, 2021 02:56 PM

   

   John,

   Thanks for the follow-up.

   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 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.

   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.

   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.

   What other reasons beside color separation might you have for wanting to divide a drawing into separate layers? Different pen widths? Other reasons?

   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.

   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?

   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.

   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? If so, would we need some mechanism to guarantee a pause between the mark and the rest of the drawing?
   If so, what would be the best way to do this? (I could imagine drawing a second registration opposite the first; the travel time to second mark and back might be enough to stop the plotter in time.) Or is there some other way to do this?

   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.

   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)?

   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.

   Floris

   • Schermafbeelding_2021-02-06_om_14.00.01.png 118 KB
   • Schermafbeelding_2021-02-06_om_14.56.56.png 135 KB
   • rearrangedgrid.ndbx.zip 1.45 KB
   • Edit

6. Support Staff 6 Posted by john on 16 Feb, 2021 06:11 AM

   

   Hi Floris,

   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:

   • A big part of designing a plot is deciding which elements to connect in a continuous line and which to separate. For this reason I think serious plotters would always use a mask node input to my image node. A mask node allows you to control exactly which pixels to include in each "line".
   • Even if you just want to plot an image directly, I would still use a hatch node mask with horizontal lines to define the rows. That way each row is a single connected line and you can control how widely to separate the lines and how often to sample along them.
   • So when passing multiple paths to a plot node it should assume each path is connected, but will lift the pen and reposition between each path.
   • As for efficiency, you're right: a general purpose efficiency routine could become complex. I will soon take a first run at it as follows:
     • An outer subnetwork will read in all the paths at once (list mode)
     • It will look at the beginning and end points of each line and build a distance matrix
     • It will use this information to reorder the lines as needed to minimize total travel time
     • It will also reverse some lines to further reduce total travel time.
     • Once the paths are reversed and ordered, it will then feed them into an inner subnetwork one path at a time.
   • Masks could become much more sophisticated:
     • You could first use the image node to do analysis and produce dynamic masks, different for each image
     • You could break an image into separate regions and produce a different mask for each region
     • You then feed each mask into a new image node and feed the the output of THAT into your plot node
     • Multiple image to mask to image to plot chains could be combined to produce the overall plot
   • Another major area we have so far neglected are the patterns for converting a luma value into a "squiggle":
     • Your first cut was to randomly scatter points and connect them: the more points the darker the cell. Simple and effective, but this only scratches the surface of what's possible.
     • I propose the concept of a "pattern set", a collection of line segments or curves arranged on a continuum from sparse to dense.
     • You would create this set algorithmically and feed it as a list into the plot node.
     • The plot node would then map the paths in that set to the range of luma values. So instead of creating dots of a given size for a given luma value, it would choose one of these patterns.
     • Different pattern sets would create different aesthetic effects. You could build your plot out of rigid lines (dotted lines for sparse, a thicket of lines at right angles for dense), curvy lines, or whatever.
     • You could also implement plotter friendly dots by simply making a pattern set of spirals: sparse small dot spiral, dense small dot spiral, sparse bigger dot spiral, etc.
     • You should be able to even feed in characters (text paths) to create ASCII Art.
     • Ideally the patterns should be designed or made to connect cleanly so the plotter can move cleanly from each pattern to the next with minimal backtracking. I need to think more about how best to do this.

   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 notice that similar tools and techniques are available on drawingbots.net. Some people offered GitHub libraries of Javascript routines to do some of the things I am describing. The advantage of NodeBox, I think, is that it should be much faster and easier to develop and experiment with new plotting masks and pattern sets.

   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!

   John

   • Edit

7. Support Staff 7 Posted by john on 17 Feb, 2021 01:00 AM

   

   UPDATE

   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.

   John

   • Edit

8. 8 Posted by florisdejonge on 18 Feb, 2021 07:26 PM

   

   John,

   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.

   Kind regards,
   Floris

   • cmyk_image_node_v2.zip 1.37 MB
   • Schermafbeelding_2021-02-18_om_20.21.35.png 862 KB
   • plot_node_crosshatch.zip 1.33 MB
   • Schermafbeelding_2021-02-06_om_08.59.41.png 572 KB
   • Edit

9. Support Staff 9 Posted by john on 18 Feb, 2021 10:53 PM

   

   Floris,

   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.

   John

   • Edit

10. 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.

    Floris

    • Edit

11. Support Staff 11 Posted by john on 20 Feb, 2021 09:38 AM

    

    Hi Floris,

    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.

    John

    • Edit

12. Support Staff 12 Posted by john on 20 Feb, 2021 10:27 AM

    

    Floris,

    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:

    • You feed the output of your convert range node (from 1 to 5) into an integer node instead of a level node. Integer nodes will round the floating point values, segregating the luma values into 5 unequal groups:
      • 1 to 1.5 gets level 1
      • 1.5 to 2.5 gets level 2
      • 2.5 to 3.5 gets level 3
      • 3.5 to 4.5 gets level 4
      • 4.5 to 5 gets level 5
    • As a result, levels 1 and 5 get 1/8th of the range each, while levels 2, 3, and 4 get 1/4 of the range each. Was this your intention?
    • When you then set the gray value for each level, instead of dividing it equally you provide five specific values: 0, 45, 90, 160, 210, 255.

    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?

    John

    • Edit

13. Support Staff 13 Posted by john on 20 Feb, 2021 11:27 AM

    

    Hi Floris,

    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.

    Progress!

    John

    • Edit

14. 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.

    Floris

    • Edit

15. 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.

    • Schermafbeelding_2021-05-13_om_14.20.19.png 241 KB
    • papersize_v2.ndbx.zip 4.24 KB
    • Edit

16. Support Staff 16 Posted by john on 13 May, 2021 07:04 PM

    

    Floris,

    Nice!

    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!

    John

    • Edit

17. 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.

    • Edit