We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
The app seems to work ok. Right now I get the best results from using black-and-white clip-art. I am working on a photo version that stipples the image first then performs the traveling salesman on it.
So the algorithms work towards a stable point. Given enough time, there would be no “links” in the art. That’s kinda the fun and frustrating thing about the traveling salesman problem, there’s likely a shorter route, we just don’t know know what it is.
The program works in this case by swapping the paths and making the route shorter and shorter until one of the swaps makes it longer again, then it stops. The program implements 2-opt to prevent the paths from overlapping, but it doesn’t necessarily force it to have the shortest path.
I’ll probably add an option to remove paths longer than x length. You wouldn’t have a single path anymore, but you wouldn’t have those “links” either.
I’d love to see the Stipling version. I could see doing that with a Vbit making little hole marks on two-layered materials to create the contrast in a picture. Are you working on making a Stipling app?
I started with a pic of a geranium and traced in Autocad with polylines. I attempted to make as many long continuous runs of “tool in work” as I could stand to spend time on. I include even a few places of “go out and back” just to try and reduce tool lifts.
I also ran it through that xyzbots optimizer (had to edit the file afterward to make it compatible with Easel - mainly just changing to all caps) to try and reduce the amount of “tool out of work” traveling.
Would your algorithm (with tweaks) be capable of “glueing” together more of the lines. Even having short backtracks is likely shorter time to cut than the Traveling Salesman code generated by Easel.
It might be possible if every line were subdivided into a series of points then apply the TSP algorithm to that set of points and remove all lines / moves longer than a given threshold limit. It should give you the same output with a reduced number of tool lifts.
Yeah, I’ll have to put a routine in the program that removes lines longer than a specified threshold. As a result you may no longer have one continuous path, but I doubt anyone would ever notice.
seriously impressive! I’m thinking it will be cool to export to svg, then have it laser-scored. It will be fun to watch the action, but it will probably burn out the servos.
I’ve done some “fractal” puzzles on the laser. It seems your app might also be adapted for that also.
Unfortunately, no. It’s only accessible to the development team right now. And I have a few… bugs… to work out . But if you have a specific use in mind that you’d want me to run it on and send to you, you can PM me and I’d be happy to do that.
. But if you have a specific use in mind that you’d want me to run it on and send to you, you can PM me and I’d be happy to do that.