Separate the packing algorithm out from the UI and SVG dependency so it can be used independently

[goatchurchprime]

The geometry part of this code depends on plain polygon objects which are lists of {x: y:} points and some worker threads that call the clipper library and a genetic algorithm.

The other half of this code decodes the SVG shapes, organizes them into inner and outer contours, and then linearizes the edges.

It would be very useful if this system were broken into two completely disconnected parts with a simple API between them (that just took the polygons and returned the transformations), because then I could use it for packing other shapes that might be generated within my own javascript UI.

[Jack000]

yeah the api is currently only abstracted to the level of SVG inputs rather than polygon inputs. It would take a bit of refactoring to also take out the SVG stuff. Shouldn't be technically difficult but would take some time. I'll have a look at this when I have time : ]

[goatchurchprime]

Just because I'd been thinking about this application before this one showed up and made most of my work obsolete.

I'm suggesting that as well as isolating the whole polygon packing from the SVG/UI part, it would be a good idea to totally isolate the individual packing routines through an interface like JSON-RPC. This makes it possible to calculate it on other tabs ( https://github.com/izuzak/pmrpc ) or even serve the work out to other servers in parallel (possibly with completely different implementations than javascript).

This genetic algorithm method lends itself to doing something amazing with, say, 200 distributed processors at once controlled by a single javascript webpage. You could organize this by distributing the geometry between all the computers that have the svgnest.com webpage open at once through websockets. The effect is you'd get your highly optimized nesting done in 15 seconds from hitting Go, but you should leave your computer open on that page for the next 15 minutes to pay back that computational debt. That sort of real-time crowd computing.

[justinclift]

Interestingly, that kind of approach would make sense for something like Chilipeppr, which runs CNC operations from a browser (thus, it's open for an extended period of time after initial setup)

@johnlauer What do you reckon? eg, if Chilipeppr had the ability to pack geometry for optimised cutting, would the above (comment before mine) be an effective approach for figuring out good placement + distributing the processing power?

For reference:

    http://hackaday.com/2016/01/22/pack-your-plywood-cuts-with-genetic-algortihms/