Requesting Nonplanar code pull

[Sazoji]

a lot of the code from this branch is incompatible with most forms of support generation done within the slicer already but for the most part, the nonplanar build runs fine on this old version of slic3r. The most I can do is fix typos and try to find out what parts are missing in order to build on ubuntu, but I'm hoping by making a request, at least part of this code can make it in.

more changes are needed before even starting to move over the code, but current features include:

• nonplanar slicing of top surface(s)
• automatic detection of incompatible regions (too high z, collision from nozzle angle)
• nonplanar layers are separated from the model and can be modified without affecting the planar layers below
• debug window showing why possible nonplanar sections where rejected from slicing
• gui integration of nonplanar slicing settings

there are two major bugs, however

• support integration on a fundamental level is incompatible
• moving models on the build plate breaks nonplanar slicing

I highly encourage reading the author's master thesis before reviewing and evaluating the code (https://tams.informatik.uni-hamburg.de/research/3d-printing/nonplanar_printing/index.php), but I hope at least part of this feature can enter a modern slicer within this year.

this looks like the same TAMS that brought Adaptive Slicing to Prusa slicer and slic3r, would be great to see another method for smooth(er) printing surfaces, even if there is hardware changes that need to be done in order to be more effective.

[lordofhyphens]

I can't accept this PR as it has lots of conflicts and a pile of commits.

[Zip-o-mat]

This was not intended to be merged into the master at the current state of development

[lordofhyphens]

Closing as this is not a true PR and there's so much divergent here (and I'm not sure why).

Please ensure your development is started from Slic3r:master

[l29ah]

I'll try updating it up to master in a few days, but it seems like much have to be rewritten as slic3r ported some relevant code to C++.

[Zip-o-mat]

I switched back to the old build system in:
https://github.com/Zip-o-mat/Slic3r/tree/nonplanar-master-merge
Maybe this helps. But all this code can not simply be merged into the master branch!

[l29ah]

I'm puzzled on why Point was effectively made a Point3 instead of using Point3 when needed. @lordofhyphens, is this ok?

[lordofhyphens]

@l29ah not really, no.

[Zip-o-mat]

I was too lazy to change Point to Point3 everywhere so I simply modified Point.

[l29ah]

@l29ah not really, no.

What would be a proper way to handle it then? The Point to Point3 change needs to propagate to Line (Line3 that is not present yet?) and into the rendering routines in the GUI.

[lordofhyphens]

It's probably okay to adapt Line into a Line3 without breaking all the code in the universe. That is, update it to always have the 3rd coordinate (default of 0), with constructors from Point and Point3.

Getting it into the GUI routines was always going to be a pain as the very nature of the thing tends to invalidate most of our draw code and UI assumptions.

It's either that or template Line and Point with an integer parameter with specializations for X=2 and X=3. I'd probably accept either approach as I do like having the assertion that something is in 2D space or in 3D space.

I also wonder if it's useful at all to have a reference X/Y/Z plane in the constructor so you can use relative coordinates.

[l29ah]

It's probably okay to adapt Line into a Line3 without breaking all the code in the universe. That is, update it to always have the 3rd coordinate (default of 0), with constructors from Point and Point3.

Sounds easy enough, but there are upper level classes affected as well. For instance, ExtrusionPath needs to be 3D, that means Polyline.points should be made of Point3's, but a lot of code refers directly to a Polyline.points, assuming Point's. I could add a separate variable to Polyline denoting the z offsets of the Points but then it will get really messy to use them and convert from and to Point3's.

[supermerill]

in my fork, i created a extrusionpath3D, extrusionMultipath3D, and now i'm using a visitor when i want something to/from an extrusion entity (no more cast).
I also modified the gcodewriter.extruderXYZ to work correctly with them.

You can grab them if you want.