Skip to content
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

Open
nickcoutsos opened this issue Apr 19, 2022 · 3 comments
Open

Optimize rendered SVG #1

nickcoutsos opened this issue Apr 19, 2022 · 3 comments

Comments

@nickcoutsos
Copy link
Owner

laser cut acrylic is expensive, and printing two copies is twice the price of printing one copy. So if you could bring both halves into one svg file and minimise wasted space, this would be a lot cheaper to print an entire keyboard.

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:

  1. Reducing the amount of material used
  2. Reducing the amount of cutting required

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).

@7t2
Copy link

7t2 commented Apr 20, 2022

/u/priornextgen here
I definitely agree with reducing the amount of material used, i.e. minimising wasted space. However I cant say I agree with reducing the amount of cutting required. I enjoy having the numbers row and minimising the amount of shortcuts needed to remember. Plus, I think trying to minimise the amount of cutting would take a lot of time and energy, and I don't think it would be worth it.

@nickcoutsos
Copy link
Owner Author

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

Screen Shot 2022-04-19 at 11 03 58 PM

@7t2
Copy link

7t2 commented Apr 20, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants