-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize rendered SVG #1
Comments
/u/priornextgen here |
Suppose you have 4 equally sized squares to cut out. You can squeeze them close together so that they efficiently use up the available material and save on space, but I'm talking about something else. In the normal cause you would make 16 cuts: one for each side of each square. Alternatively, you could bunch up each of the squares and make only 6 cuts because 8 of the square edges are shared by other squares and therefore don't need to be cut again.
vs
If you're only interested in the space optimization you can pass the SVG through a tool like SVGnest |
That is an excellent idea, as long as it takes into consideration laser width and you feed it a correctly sized SVG and get a correctly sized SVG out. That will save big time on costs, it looks like you'd be able to print both halves out for less than $50 AUD |
The SVG shown in the repo can certainly be used as a cutting template as-is, but it hasn't been optimized. I mainly wanted to illustrate the output of this codebase: 2D geometry.
Optimization is an interesting problem, and not entirely straightforward. I see two types of optimization:
The first kind of speaks for itself. I think the keyboard I built in 2018 cost somewhere shy of 100 CAD to cut, and now that we're entering year three of a pandemic I don't know if acrylic is getting any cheaper. The fewer parts we have to cut, the better. The more optimally we pack those parts, the more we can get out of a single sheet of acrylic. There are complications to this: the service I went to charged for a minimum sized sheet that was already more than I needed for... probably two full keyboards. But different services will have different constraints, and some may even let you supply your own material.
The second one kind of builds on the "cut less stuff if you can" idea and throws in curveballs like making edges of different pieces touch wherever possible so that they share cut lines. This one I can't actually do before rendering the SVG or else OpenSCAD would combine them into one larger path.
Another aspect is customization. I pre-rendered the cutting template for a 6x5 dactyl with the 1.5u + 1u outer column because it was easier to get a cheap set of Ergodox keycaps, but I know that's not for everyone. I don't even use a number row these days.
All this to say, some of the optimization will have to happen on the end user's side. I'm not against implementing some that I can, though I'll be relying heavily on third party libraries (I'm looking at SVGnest so far but that solves problem one, not problem 2).
The text was updated successfully, but these errors were encountered: