Initial port of the new ensure vertical thickness algorithm from PrusaSlicer

[Noisyfox]

Based on prusa3d/PrusaSlicer@1a0d8f5

This gives quite a lot of filament & time reduction with better infill patterns.

[Noisyfox]

This also fixes #2081

[Noisyfox]

There are some clean up work to be done, such as removing the "Detect narrow internal solid infill" as it's replaced by this as well. But it's overall complete and can be tested now.

[Eldenroot]

@Noisyfox - what else is on the list (I mean porting from PS/SS)?

I had been using PS for more than 4 years? Now I swicthed to Orca slicer (2 months ago) because Bambulab printer.

I am just curious, I love a lot of options and settings for customization and push the limits of the slicers :) thank you for your hard work! I have many ideas and requests but I see that you are busy with these ;) Contact me via Discord if you are interested ;)

[Noisyfox]

@Noisyfox - what else is on the list (I mean porting from PS/SS)?

I had been using PS for more than 4 years? Now I swicthed to Orca slicer (2 months ago) because Bambulab printer.

I am just curious, I love a lot of options and settings for customization and push the limits of the slicers :) thank you for your hard work! I have many ideas and requests but I see that you are busy with these ;) Contact me via Discord if you are interested ;)

On top of my list is to make the new arrangement algorithm from Prusa to work with multi-plate. Some other things like the extrusion role change g-code from SS are also considered.

If you got any suggestions/ideas, you can just create github issues or post in Discord's dev channel.

[igiannakas]

Love it! Fantastic work!

[igiannakas]

Build a local copy of this feature. Works great actually.

It keeps the concentric infill in places where it's needed, ensuring speed is retained while optimising bridges and the amount of it.

In addition for complex organic models, it saves quite a bit of filament and print time. For example in the pumpkin model below it saved almost 2 hours print time and 36 grams of filament!

Left side with this PR, right side current 1.8 build.

That's some good work there porting it over.

[Eldenroot]

Great!!!

[SoftFever]

This also fixes #2081

Interesting!
How does this fix this issue? Prusa didn't use some magic number?

[Noisyfox]

This also fixes #2081

Interesting! How does this fix this issue? Prusa didn't use some magic number?

It detect layer above bridges and avoid using the concentric infills. It also detects the orientation of the bridge and make sure the infill above it won't go the same direction:
https://github.com/prusa3d/PrusaSlicer/blob/94290e09d75f23719c3d2ab2398737c8be4c3fd6/src/libslic3r/LayerRegion.cpp#L453-L455

The new LayerRegion::process_external_surfaces handles the infill differently based on where they are.

[discip]

@Noisyfox

1. Something interesting is going on with the internal solid infill:
   cephalopod.3mf

   As you can see there are parts of internal solid infill that start in mid air:
   On the right is the result from your PR on the left, the result from the version prior to this:
   
   

   For this layer the previous version performs better.
   
   

   
   
   

   For this one actually exactly the opposite is true.
   
   

   

   
   Maybe this could be fixed so that it always starts from already existing walls.

2. And there is one more thing about the difference between the behavior of the internal solid infill when Arachne is used compared to when Classic mode is utilized.

   In both cases the orientation of the first internal solid infill-layer is the same (picture on the bottom).
   However, the Internal Bridge-layer with Arachne is parallel to the internal solid infill, whereas with Classic mode is it rotated by 90° (as it should).

btw:
Is the way the internal solid infill is generated expected to come out like this?
In the previous version it consisted only of concentric paths.

[Noisyfox]

@Noisyfox

1. Something interesting is going on with the internal solid infill:
   cephalopod.3mf
   cephalopod.gcode
   As you can see there are parts of internal solid infill that start in mid air:
   On the right is the result from your PR on the left, the result from the version prior to this:

   For this layer the previous version performs better.

   

   For this one actually exactly the opposite is true.

   

   Maybe this could be fixed so that it always starts from already existing walls.

2. And there is one more thing about the difference between the behavior of the internal solid infill when Arachne is used compared to when Classic mode is utilized.
   In both cases the orientation of the first internal solid infill-layer is the same (picture on the bottom).
   However, the Internal Bridge-layer with Arachne is parallel to the internal solid infill, whereas with Classic mode is it rotated by 90° (as it should).

btw: Is the way the internal solid infill is generated expected to come out like this? In the previous version it consisted only of concentric paths.

For the first point, I don't think it matters as it's not really print in mid air, as it's overlapping with the layer below. I get that this could be improved and I'll try to solve it but the algorithm is complicated and I'm not sure what side effect might occur if I touch anything. And since PrusaSlicer has the same issue, I think we can live with this for now.

For your second issue, could you share the project?

[discip]

1. Yes, that's true, but as you yourself have pointed out, it would be nice if this were improved. 😊

2. Here you go:
   spacer.3mf.txt

[igiannakas]

Think I've found a bug in the implementation. It seems that it breaks the internal solid infill pattern selection. All internal solid infill now prints as monotonic.

See below - internal solid infill pattern selected is concentric and the print is monotonic.

[Noisyfox]

Think I've found a bug in the implementation. It seems that it breaks the internal solid infill pattern selection. All internal solid infill now prints as monotonic.

See below - internal solid infill pattern selected is concentric and the print is monotonic.

Ah you're right. Prusa does not have internal solid infill pattern selection so their code does not take that into account. I'll see if I could add that.

[Noisyfox]

Think I've found a bug in the implementation. It seems that it breaks the internal solid infill pattern selection. All internal solid infill now prints as monotonic.

See below - internal solid infill pattern selected is concentric and the print is monotonic.

This should be fixed now.

[Noisyfox]

@Noisyfox

1. Something interesting is going on with the internal solid infill:
   cephalopod.3mf
   As you can see there are parts of internal solid infill that start in mid air:
   On the right is the result from your PR on the left, the result from the version prior to this:

   For this layer the previous version performs better.

   

   For this one actually exactly the opposite is true.

   

   Maybe this could be fixed so that it always starts from already existing walls.

2. And there is one more thing about the difference between the behavior of the internal solid infill when Arachne is used compared to when Classic mode is utilized.
   In both cases the orientation of the first internal solid infill-layer is the same (picture on the bottom).
   However, the Internal Bridge-layer with Arachne is parallel to the internal solid infill, whereas with Classic mode is it rotated by 90° (as it should).

btw: Is the way the internal solid infill is generated expected to come out like this? In the previous version it consisted only of concentric paths.

Ok so for the second one, the issue is actually caused by the bridge direction, which I think is irrelevant to this PR. The bridge direction and infill direction is a long standing issue I believe and you can workaround by changing the infill/bridge direction.

On a second thought, we might be able to add something that preventing the bridge direction auto detection algorithm to use the same direction as the infill direction of the upper layer. That'll be a separate ticket though.

[discip]

I have no particular idea on how to solve this. My intention was just to prevent later fixes. 😊
As you are the one in the know I think you will do just the right thing! 👍

[SoftFever]

@Noisyfox
Awesome work!
It's almost ready to merge. Only need to handle the legacy after deleting an option(refer to my code review)

[SoftFever]

A big shout-out to everyone who participated in the testing! Your contributions are invaluable too 🥇

[SoftFever]

Merged.
Thanks for fantastic work!