[suggestion] 2D plotter / drawing / printing option

[ES-Alexander]

It'd be nifty for people to be be able to put in some text or an image and get a meaningful gcode output, for things like drawing with a pen (or painting) on a page, or printing a design onto some fabric, or printing as a top layer that then gets painted or used as a stamp.

A couple of spit-balled ideas:

1. allow text input that draws the letters with single width passes (instead of the doubled borders a slicer would tend to make)
   • would require one or more fonts to be included, which could either be manually defined as points, or (more advanced) automatically converted from common computer font files
   • to some extent this is covered by SVG import #11, but I'm thinking of filled fonts rather than letter outlines
2. allow (raster) image input that gets drawn in some interesting way
   • Canny edge detection would be a quite simple option, to draw just the detected edges from the image
   • more advanced/artistic approaches could do some form of shading using things like
     • variable width parallel lines with even spacing
     • squiggly non-crossing fixed width lines that use some form of iterative point adjustments to create lighter and darker regions by density
     • variably spaced hatches
     • variably oriented straight lines that each cover the darkest remaining line in the image
     • variably sized filled circles, either in a grid or haphazardly packed
     • something Voronoi based
   • this kind of thing might require Pillow or opencv as a dependency, in which case it could be useful to create multiple install targets depending on what features people want (e.g. pip install fullcontrol[all] vs pip install fullcontrol[minimal] and such)

[fullcontrol-xyz]

These are great ideas! I've been thinking about single-line text for some stuff I want to do with pen drawing. There are some fonts out there that are single line. But there would need to be some method to convert the ttf to svg in python unless it's acceptable to have a workflow where other software like inkscape is used to create an svg of the single-line-font text.

The image stuff would also be really cool and very achievable. I think the best bet would be to initially get a parallel line version working by simply varying z-position and using a soft-tip pen. You'd just create a load of line segments with x/y following a square-wave or square concentric spiral or similar, and for each point z would be set proportional to greyscale value (or some fancy non-linear relationship for z:greyscale. If each line segment ended in the 'middle' of a pixel, this would be so simple to do. Or if not, it might still work by sampling the image data, if the appropriate resolutions for image/toolpath are used.

If someone has a pen-plotter for which this would work, comment here and let's get something up and running

[ES-Alexander]

A few initial results from a bit of playing. Left image was the input, the others are some different outputs that could potentially be 'drawn' by a printer (rightmost is your square concentric spiral idea):

I should hopefully be able to upload a gist in a few days - my code is not yet using any of the fullcontrol codebase.
One of the fiddly parts will be in displaying the expected output (rather than just the toolpath), because plotting libraries don't tend to like displaying points or lines with their sizes/widths in plot units, so we'll need to either plot the line segments as individual shapes (e.g. rectangles and trapezoids), or draw things in a rasterised format instead (which is likely less desirable, but better than nothing).

[fullcontrol-xyz]

Looking good - that makes sense about line widths. It's something I really wanted to do in the basic FullControl plot, but ran into challenges when trying to have multiple lines widths on the same line, as you've mentioned.
In the future, it will be really valuable to have a way to plot continuously varying line-widths for 2D and 3D line plots. But it also becomes valuable to have some kind of shading to avoid lines merging visually into big regions of solid colour. It's possible with threejs, but difficult to make versatile for all the different types of toolpaths that might be designed. Hence the simpler plot style in FullControl initially.

For this 2D approach in the short term, what about plotting each line as a (long) closed polygon? A series of points offset from the line medial axis by width/2. This would be possible directly in plotly - generating the points is where the most effort is required. There'd be a new polygon for each new line (and each time the pen lifts off the paper due to white pixels). Alternatively, if the whole plot is one single polygon with infinitely narrow connections between lines, that would make plotly run much quicker. It just depends whether plotly shows those infinitely narrow connections unintentionally.

[ES-Alexander]

In the future, it will be really valuable to have a way to plot continuously varying line-widths for 2D and 3D line plots.

Agreed. What kind of profile are you envisioning for the 3D side of things? 2D width is at least conceptually straightforward, but 3D might need some concept of collisions and flattening in order to be visually accurate, which gets complicated fast. I suppose it could be possible to do cylinders+cones as an analog of the rectangles and trapezoids in the 2D domain, but I'm unsure how limiting that will be for more complicated designs that involve connections and/or some form of layer stacking.

For this 2D approach in the short term, what about plotting each line as a (long) closed polygon? A series of points offset from the line medial axis by width/2.

Yeah, that's the kind of thing I was thinking - I'll have to look at what's available.

As is I did the rightmost plot as a matplotlib LineCollection (and the others were just defined as pixels in raster images), but I don't like needing to manually interpolate steps at the width changes, so using polygons is a better choice if it's feasible / not too computation heavy (not to mention that matplotlib's linewidths are in pixel units, so aren't good for physically consistent plots). Ideally it'll be possible to define something that's easy to use and interoperates nicely with plotly, but (having not looked into it yet) I'm not sure whether that's best handled on the Python side or the javascript side / within plotly itself.

I suppose if performance is an issue we could make a variable_widths flag in the plot function or something, that falls back to the current line approach if it's disabled.

[fullcontrol-xyz]

For the 3D stuff, I know threejs has some easy-to-use 'tube geometry' options that shade nicely to give clear visual representation even if the tubes overlap a lot. But the js would need to be dug into to make that work since the default threejs functions work on 'paths' and these don't handle print paths of discrete points well. It's probably easy for a threejs expert to do, but would take a fair bit of time for me (Andy). The maths has already been done by someone to get the cylinders (actually polygons) to connect neatly at the ends, etc., so it's probably not that difficult. But this route obviously has some complexity involved in communicating between python and js. But that's something that FullControl can simplify for end-users. I'm sure there are loads of other options too. It may depend on whether someone comes along who interested in FullControl and has some relevant experience to be able to knock up a really great visualiser. At that point, it'll probably be best to consider more general stuff too (beyond just 3D variable-width lines), like animations, etc.

I think the 2D polygon idea should be fine in either python or javascript, since there probably won't be toooo many polygons. So I'd do as much as possible in python so it can easily transfer over to other visualisation packages if people prefer not to use plotly. E.g. it'd be easy for someone to convert those polygon points into an SVG.

[ES-Alexander]

Noting for future reference: Plotly Streamtubes look promising.

[fullcontrol-xyz]

Ah it does! And it has some shading which is important

[ES-Alexander]

Quick update:

1. I tried the streamtube approach and didn't make much headway with it
   • given what it's designed for it seems unlikely to play nicely with sharp corners and path intersections, both of which are common in machine toolpaths
2. I spent a bunch more time starting a path points -> tube mesh converter
   • I've sorted out a suitable code structure for generating cylinders / cut cones with variable end diameters, but
   • there are some intricacies with determining reasonable mesh points at the path ends and corners that I'm still working through
   • I'm hopeful I'll complete that over the weekend, and be able to start applying it to paths to see how it goes performance wise
     • I have put at least a little bit of effort into minimising redundant operations and memory usage, as well as avoiding unnecessary polygons in the generated mesh (while also being able to turn up the resolution on demand)
     • I've just had the thought that I might be able to add a "ribbon" mode or function, which would conveniently also serve as a high performance option for flat plots as well... - I'll have a play

... it has some shading which is important

Thankfully this seems to be the case for plotly's mesh rendering in general - you can even specify things like the location and orientation of the light source :-)

[fullcontrol-xyz]

Shame about streamtube, but the other stuff sounds great! I presume a lot of the work is for the geometry side of things rather than plotly-specific stuff? If so, for the corners, check out the threejs tubegeometry code. I haven't dug beyond the top-level stuff, but I think all the maths for points must be accessible since it's open source.
I'm sure you already know better than me, but in the ideal case, your code would be easy to reuse for other visualisation approaches that may come in the future. E.g. to output an stl file

[fullcontrol-xyz]

And thanks so much much for all the effort!!!

[aapolipponen]

Do you guys have a plotter already? I have a 3d printer that has an plotter attachment I built, so I can test the system if needed.

[ES-Alexander]

FYI, current state of my visualisation code is in this gist. I decided to change approach from my initial one to simplify some of the required maths by using global coordinates, so there's now working functionality, but it still needs some revising of the mesh generation before it'll be properly ready/nice - specifically at the corners / changeover points between path sections.

[ES-Alexander]

Do you guys have a plotter already? I have a 3d printer that has an plotter attachment I built, so I can test the system if needed.

@aapolipponen I don't have a plotter, and I believe @fullcontrol-xyz don't have one either.

I'm currently focusing on this visualisation thing before I get more properly into realising my plotter ideas, but if there's something in particular you're interested in testing I can potentially throw together a code snippet to generate some points or gcode or something (like I was playing with earlier).

[aapolipponen]

The 3d printer is actually not even working right now, but the parts for the repair are coming in something like two weeks, so no rush. I just though that if the code needs testing, I could help with that.