SVG nest integration

[JulianTodd]

Here's an interesting experiment, as a follow-on discussion of the work done in the Arch Workbench.
https://forum.freecadweb.org/viewtopic. ... 4&start=10

The basic idea is to note that a Path Job object contains one Stock shape and a list of Body shapes (inside the Model component), which is enough input to a nesting feature. -- We could use a tool diameter to set the spacing to represent the width of the tool/water-jet/laser that cuts out the parts from the stock shape.

Instructions:

1) Select the Job and run the macro "jgt_svgnest_job.FCMacro" and click on [Cancel] when it asks you to open an SVG file.
This will cause it to save the geometry into the file "~/.FreeCAD/svgnestinput.svg"

presvgnest.png (168.96 KiB) Viewed 3012 times

2) Upload this file to https://svgnest.com/ , click on the stock outline, click on start nest, and let it run for a while, then press Stop nest, and download SVG.
Actually, you're not really "uploading" your file, because it's actually running in Javascript in your browser.

svgnestrun.png (72.61 KiB) Viewed 3012 times

3) Run the macro "jgt_svgnest_job.FCMacro" again, and select the SVG file you just downloaded in step 2.

postsvgnest.png (173.04 KiB) Viewed 3012 times

Result: All the bodies in the Job.Model.Group will be given new Placements which match those calculated by SVGnest.

The github code is here (as well as the code being attached)
https://github.com/goatchurchprime/tran ... r/nesttest


The code is very short and depends on Path.fromShapes() to extract the geometry, which is then written out as SVG.

I'd like to do this in pure python, but this gets it done quickly, and is a FAR better option than using Drawing.projectToSVG(), which does a horrible geometric projection before providing lots of fragmented paths. Clean geometry that you get from fromShapes() is easy to transform into the SVG format.

Luckily, the transforms and rotations defined in the SVG format work perfectly in the Placement object.

I'd be interested if anyone is able to replicate this, and whether it can be useful.

[sliptonic]

I was able to duplicate your results using your test file. Very cool!
First attempt with my own file didn't work as well. File attached.

Code: Select all

Traceback (most recent call last):
  File "/home/brad/Dropbox/FREECAD/jgt_svgnest_job.FCMacro", line 109, in <module>
    writesvgnest(job, fnameout)
  File "/home/brad/Dropbox/FREECAD/jgt_svgnest_job.FCMacro", line 74, in writesvgnest
    stockface = extractflatfaceofbody(job.Stock)
  File "/home/brad/Dropbox/FREECAD/jgt_svgnest_job.FCMacro", line 36, in extractflatfaceofbody
    assert len(basefaces) == 1, len(basefaces)
<type 'exceptions.AssertionError'>: 0

[yorik]

Very, very interesting! Our nesting implementation is really feeble, while svgnest is our there since a long time and way more powerful and reliable.

[JulianTodd]

My mistake. Very sorry.

The function extractflatfaceofbody(), which is supposed to extract the flat 2D face from each body, assumed that this face would always be on the base plane Z=0. It failed on the stock shape because the default is to offset the Z dimension by +1 and -1 from the bounding box.

I've rewritten it so it simply picks the horizontal flat plane which is the lowest:

Code: Select all

def extractflatfaceofbody(body):
    basefaces = [ face  for face in body.Shape.Faces  if face.Surface.isPlanar() and abs(face.Surface.Axis.z) == 1 ]
    basefaces.sort(key=lambda X: X.Surface.Position.z)
    return basefaces[0]

Get a replacement of the macro code from this directory: https://github.com/goatchurchprime/tran ... r/nesttest

The SVGnest function can handle non-rectangular shapes for the bin -- so you could potentially import a shape from a photograph made of the cutting area from above, so you could get a workflow as efficient as shown here: https://www.youtube.com/watch?v=fG2c19wOIeA

Producing an efficient integrated workflow in some manner that can be used daily, no matter how cobbled together, is the way to get this software into the productive world.

The interface (not the SVGnest algorithm) would allow for nesting in 3D, which is a feature needed in SLS, https://www.3dprint-uk.co.uk/ultimate-guide-nesting/

These general-purpose algorithms are abstractly easier to work on outside the FC system, because it's a relatively small amount of data flowing out and in (especially inwards, as it's no more than 6 numbers per item). The algorithms also don't need to be absolutely optimal to be good.

The main headache is always the UI interface, which appears to be for free, given the components already in the Job object -- no having to specify shapes and stock position, and here the data is seamlessly brought back in.

We could put SVGnest on the other side of a http socket, and then the macro could simply send up the geometry as SVG codes up to that, and then wait for updates of the positions coming back down. It can update with a better result every 30 seconds, until you click stop, and the processing concludes.

I think all the toolpath calculation algorithms should be implemented this way, outside the FC system in a separate process with geometry communicated through a socket.

[Kunda1]

There is a Slic3r GSOC 2019 student that is porting svgnest to c++
https://brlcad.org/wiki/Google_Summer_o ... to_C.2B.2B

[RatonLaveur]

Us laser guys would be over the moon...

[dubstar-04]

There is a Slic3r GSOC 2019 student that is porting svgnest to c++
https://brlcad.org/wiki/Google_Summer_o ... to_C.2B.2B

That would be a super nice feature!