Nester

Info about new community or project announcements, implemented features, classes, modules or APIs. Might get technical!
PLEASE DO NOT POST HELP REQUESTS OR OTHER DISCUSSIONS HERE!
User avatar
Kunda1
Posts: 3671
Joined: Thu Jan 05, 2017 9:03 pm

Re: Nester

Postby Kunda1 » Sat Aug 25, 2018 2:03 am

Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features
chrisb
Posts: 13305
Joined: Tue Mar 17, 2015 9:14 am

Re: Nester

Postby chrisb » Sat Aug 25, 2018 5:33 am

Kunda1 wrote:
Sat Aug 25, 2018 2:03 am
Have you seen Deepnest ?
Yorik brought this up some time ago: https://svgnest.com/, it seems to be the same source.
User avatar
yorik
Site Admin
Posts: 10605
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Nester

Postby yorik » Sat Aug 25, 2018 9:55 pm

Yes it's till apparently the same thing, only now it has been extended with several other functionalities. The DXF interface is especially interesting...
JulianTodd
Posts: 46
Joined: Tue Oct 23, 2018 3:35 pm

Re: Nester

Postby JulianTodd » Fri Dec 14, 2018 2:35 pm

I think we can extend the nester to the Path/Part design workbench, by taking the stock shape as the container, and the Z-flat faces of the bodies that we want to cut out from the stock.

I have had a look at running this nester from Python, and it seems to depend on having a set of shapes that contain one face each.
https://github.com/goatchurchprime/tran ... test.ipynb

All it needs to do is instead take the face itself (not the shape with one face), and it might extend easily.

This would be used for nesting a set of parts to be routed, or cut out with a laser cutter or water jet.

We need the feature to set a clearance distance between the faces. (Maybe this could be hacked into the above application using an offset shape).

It is more important to establish a general-purpose interface to a nesting algorithm that includes all the features, than it is to write a fully optimal implementation of the algorithm. If you do reimplement the algorithm, then it should be done abstractly, away from all the functionality of FC, and preferably in a completely separate process/executable.

The job of the implementation in FC would be to run the UI and package up the geometry into some polylines or curves (I like the SVG encoding of a 2D shape, because it's in ascii, has all the curve types, and can encode islands in a single string), and then stream it to the stdin of a self-contained executable program, which would return a set of numbers representing the optimal placements.

With a bit of luck, this self-contained nester could be a compiled javascript distribution of SVGnest running from a command line, which would save a lot of work on many people's parts, and make sure that FC developers keep on top of stuff that really matters -- rather than what is fun to program.

(I am really talking to myself here, because for a long time I have had thoughts of writing my own really high performance multi-core nesting algorithm, and I have to fight hard to avoid giving in to this temptation!)