Inkscape/SVG features not supported

You’re just splitting hairs at this point. If speed is an issue people just need to realize they’re up against a wall when they choose 40/45watt hobby machines instead of higher power production units.

If you’re seeing really random behavior like partial line segments being cut, then the laser jumping elsewhere, and later coming back to finish a line segment, that’s a file design issue.

2 Likes

That’s great. Can you point me to where to find the solution? Google Nav & Waze have lots of issues that I’d love to find a solution for. I participate in a sport where this is the fundamental problem - how to route between hundreds of locations optimized for speed or distance or a combination. In fact every two years there’s a national event where 100+ folks attempt to do this over 2 weeks and the North American continent. They cover between 10,000 and 15,000 miles doing it :slightly_smiling_face:

If it’s proprietary information or part of a product I’d still be interested. I might be able to point you to a new market.

I stay pretty attuned to TSP solutions but didn’t realize it had been cracked. Seems like a Nobel Prize in mathematics is warranted but I know they like to see several years of real world experience before making the award.

But I’m also talking about something more than 2-5% improvements. The TSP is about finding the optimal solution. For lasers 2-5% is virtually meaningless - 12-30 seconds on 10 minutes of cuts. It would still be meaningful for my other case though - over 10,000 miles and 264 hours even 2% would often be enough to avoid being shutout because of late arrival. Any help there would be worth $.

1 Like

I’m trying not to bang on about it, just having my face rubbed in it by the stuff I’m cutting today and people telling me it can’t be done when it can.

Theoretically, when you keep adding points to the Travelling Salesman Problem, the time taken to solve it gets a lot worse. In practice, computers are flipping fast these days and solving TS (or path optimisation) is trivial because you just throw compute time at it - and that compute time amounts to almost nothing.

Even then, we are not trying to create a perfect sequence, just a faster one. So it would go something like this.

  1. Group all paths by colour (so we can cut/engrave/score etc)
  2. Sort all paths within a colour by their starting point proximity to 0,0
  3. Scan through the paths and check the end point of the next path - it might be very close, if so, reverse the order of that path
    4) While you are here, check whether this path will create a hole within a hole - fix the order so smaller holes come first (I think), this is a simple bounding box inside poly test

Now that is almost no code. 1/3 is already being done (the colour group), 1/3 is on the list of things to do (holes within holes), that just leaves the simple bit in the middle - which won’t be perfect, but will improve a lot of cuts.

And again, I agree with Dan, not the highest priority, but it is doable and it is easy.

Were your statement remotely true, then it wouldn’t be Nobel Prize-worthy and yet thousands of mathematicians think it is. So, in the absence of a real solution and just approximations that are a little better, I’m with Dan - isn’t worth it. I used to do it with my designs when I was running my K40 or Redsail more but unless I’m making a hundred of something it’s not worth the effort. Like I said, even 5% isn’t worth much real time in a laser job - I waste more futzing with magnets or moving stuff around in my shop.

There are 50 things with the GF that more than one person here is willing to swear is trivial to fix but only one person has stepped up and backed that claim up. He built a nice little Chrome extension to save custom materials & settings. Everyone else (including me) is armchair quarterbacking from the sidelines.

2 Likes

While the traveling salesman problem is NP-hard* it’s also true that applying certain heuristics can allow you to find a “good enough” solution most of the time. We don’t need an optimal solution to speed things up. Any improvement is useful. As one of the most-studied problems in computer science, there are many, many approximation algorithms for the TSP out there which Glowforge could choose to implement. So @sqw is correct, it would be trivial to improve the sequencing of cuts/scores.

I’m also pretty sure it’s not worth Glowforge’s time to do this right now. They have many missing features and bugs to work on before they get around to making small optimizations.

* NP-hard is a class of well-studied problems in computer science that are believed (but not yet proven!) to have no efficient solutions. Easy problems in computer science run in polynomial time (or faster). That is, for some input of N elements, the time needed to solve the problem on that input is a polynomial with respect to N. For example, sorting a list can be done in N^2 steps, or even N*log N steps if you’re clever. NP-complete problems are thought to be unsolvable in polynomial time, as all solutions we’ve come up for them require exponential time (e.g., 2^N steps for the traveling salesman problem).

Yep, that’s my read on it too. It’s like ultralight backpackers - shaving grams off of the weight of a toothbrush and not doing anything about the extra 10,000 pancakes they carry around their waist :smile:

While it may be trivial to code something to save 10 or 12 seconds of time on a cut, it’s hardly worth focusing on. I’d even argue that today’s announcement of the iOS app and the Silver MacBook automatic settings weren’t worth whatever effort they took vs some of the other things we’ve been waiting on.

It is funny you should say that, because I’ve been contemplating exactly that, a utility to prepare your SVG in advance, unfortunately I can’t do that because the GF cut order seems so random…

Having just done a little testing, sorting the SVG would be reasonably easy, but the GF ignores the ordering of the SVG anyway. In fact I really cannot work out why the GF orders cuts the way it does.

@scott.wiederhold has done a lot of work noodling around in the PULS files and the logs - maybe he can help tease out what the logic behind the order might be.

As mentioned before, the GF orders the cuts by color.

So you can optimize the ordering of cuts by giving them the right ordering of color.

But then you might have the problem of having to specify in the GFUI a lot of cuts, engraves, and scores.

1 Like

I’ll file that under “Wild speculation”. Three assumptions come to mind:

  • assuming that their existing code is organized such that this would be easy to adjust
  • assuming that GF has staff and other resources necessary to do it
  • assuming this is a big enough issue to take priority over other tasks

… but these are very big assumptions. Given that @dan has specifically addressed this and said it’s not a priority, I’d say the issue is kind of dead for now.

Generally the pathing is fine for what I do (and judging by the small number of complaints on the matter, I’d say most). I’m suspicious of your specific svg if you’re seeing really weird stuff, which makes you a strange edge case, and I don’t need to tell you about the diminishing returns for diverting resources to fix those.

1 Like

Thanks for the suggestions! I’ll make sure the team gets them.