A workflow for sand art

  • Find a SVG that you like. Silhouettes work well.
  • Open Inkscape. Set the document size to your table’ size.
  • Import and scale the SVG to the desired size.
  • Use http://jscut.org/ to generate a .gcode toolpath from the SVG. ‘Engrave’ or ‘Pocket’ works well. Pay attention to the tool diameter. Save the gcode.
  • Import the gcode into https://sandify.org/ to remove feed rate changes.
  • Plot

https://ncviewer.com/ might be useful to rearrange a few contours or redirect a stray travel move

I don’t find Inkscape’s gcode plugins to be that useful, but if the SVG is already just the path you want to plot then “path to gcode” can do it.

Does anyone have a tool to re-route travel moves (or moves longer than a certain length) around the perimeter, or to do a sort of shortest path through the existing grooves so that less artwork gets rolled over?

3 Likes

Sandify should do the first. The second is much harder to do.

That patterns looks awesome. I know Karl had a pattern setup that used inkscape.

The background is a sandify Koch snowflake.

This perlin landscape tends to have travel moves near the edges that could be heuristically rerouted instead of overwriting the pattern

1 Like

Take this reaction diffusion pattern for example. The moves are identified by the long straight lines or G0 / G1 if those are preserved. One way to optimize this would be to have the plotter first plot all islands (lines that do not touch the edges). It should convert moves into a move to the nearest edge, and then a path around the perimeter to the point nearest the next draw move. If a finger reaches from the edge into the center of the drawing only, it should be converted into a path that doubles back on itself to return to the edge.

diffuse_4x.gcode (716.7 KB)

Ah. Yeah, that’s going to be hard. Because sandify doesn’t know much about the gcode coming in. So those connecting lines look to it like they are intending to be there. It doesn’t know about Z, so it doesn’t know you don’t want to travel across the middle of the pattern without touching the sand.

Instead of knowing about Z, it could know about reordering G0 commands and preserving G1 commands. But I haven’t looked inside sandify to see if it is a good place to host that kind of algorithm.

I’m using another parser for the gcode. I think I would know G0 vs. G1. If I read each set of connected G1 commands in, then I think Bob’s traveling salesman code can do the optimization. I don’t think it does retrotraverse though. That sounds possoble, and a good day’s work.

1 Like

TSP is a good idea. The TSP curves have the property that they don’t intersect themselves. It might jump from one curve to another in an unpredictable way but depending on the shape it might not be noticeable.