Porting support from Prusa Slic3r to Slic3r

[Zip-o-mat]

Version

1.3.0-dev

The support is already reimplemented into c++ in the Prusa fork. bubnikv already mentioned in #4061 that the implementation is "already stable, very fast and fully parallelized."

I looked into the code and it should be relatively straight forward to port the support code. I would try to port the support code to slic3r but I need some feedback.

Differences that I found so far:

• Pillar Support seems to generate hexagonal support structures
• The Prusa slic3r uses Threading Building Blocks.
• The Prusa slic3r generates the support based on a grid rather than following the contours of the object (see picture below)
• The Prusa slic3r generates a interface that is larger than the actual support structures.

Which features should be ported from the Prusa Slic3r and which should be reimplemented because the current slic3r implementation is "better"? What are your suggestions porting the support from the Prusa fork?

[lordofhyphens]

I looked very briefly at the Prusa3d implementation.

1. Hexagons might be preferable as pillars to squares. My suspicion is that the less-sharp corner requirements on a hexagon would play nicer with most printers than squares.
2. I'm not sold on the use of TBB at all. If we can do this with just the Standard C++11 library I'd rather do that.
   • C++14 is also feasible, but I'd rather not upgrade all of the compilers again (and I think @alexrj would not want to upgrade clang again).
3. I prefer generating support based on the contours of the object.
4. I don't know what's going on with the interface layers either.

I had collected a list of requirements for support (to drive tests and software) at https://github.com/alexrj/Slic3r/wiki/Support:-Requirements. I would much prefer it if our supports fulfilled those requirements.

[bubnikv]

I'm not sold on the use of TBB at all. If we can do this with just the Standard C++11 library I'd rather do that.

TBB implements a thread pool, which C++11 does not have (yet). On platforms like Windows where starting a thread is not quite cheap, it improves threading performance. There are other benefits like load balancing when spawning subtasks and there is no such support in C++11.

I prefer generating support based on the contours of the object.

There are two reasons to inflate the support regions into the grids:

1) It simplifies the contours, therefore it runs faster.

2) It makes the physical support stable with the cost of a bit more support than necessary in some cases.

The current support algorithm by @alexrj simply does not finish at all on complex models due to the complexity of contours, which are created by thousands of accumulated 2D booleans. Cura solves it by a quite complex simplification algorithm, which fills concave corners, but does not shrink convex corners. I thought of that as well, but the simple grid solution is faster and as a side effect makes the supports more stable.

On Thu, Nov 2, 2017 at 5:37 PM, Joseph Lenox notifications@github.com wrote:

I looked very briefly at the Prusa3d implementation.

1. Hexagons might be preferable as pillars to squares. My suspicion is that the less-sharp corner requirements on a hexagon would play nicer with most printers than squares.
2. I'm not sold on the use of TBB at all. If we can do this with just the Standard C++11 library I'd rather do that.
3. I prefer generating support based on the contours of the object.
4. I don't know what's going on with the interface layers either.

I had collected a list of requirements for support (to drive tests and software) at https://github.com/alexrj/Slic3r/wiki/Support:-Requirements. I would much prefer it if our supports fulfilled those requirements.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/4179#issuecomment-341481643, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I6UstOa0_UZA9sYAg1ZwwyzIMhN8ks5sye-3gaJpZM4QP2kB .

[platsch]

While I generally also prefer contour based support, the grid approach would be an advantage when it comes to interactive user manipulation. Adding/removing blocks of support could be based on grid cells, e.g. left click a cell to add / right click to remove support.

[Zip-o-mat]

I will first start to port the implementation as it is. We can then later test if contour following slows down the support generation too much and if TBB is speeds it up significantly. I will then also take a look at the list of requirements for support and try to meet all of them.