Prints circles on nothing - algorithm mistake on bridging operations

[gitcnd]

Application version 4.8

Platform Mac

Printer Anycubic Chiron

Reproduction steps

1. Print a lego brick without supports
2. Observe how it plans to extrude the underside of the pegs by printing on thin air

Screenshot(s) Yes. Bug report #2 - you're using legacy bug-reporting web software that doesn't appear to support screenshots - help us to help you by making it easy for us to tell you what we mean eh? https://mega.nz/file/88cHnKaD#HEX4YMwt1CQ7BTHKQStlaGHtpwvtNHfuX5GLE4Xf54A

Actual results Plans to extrude curves on air

Expected results Should plan to extrude straight bridging lines, between existing printed surfaces

Project file https://mega.nz/file/lwcX3SgL#tIxqOfMW92DKAO3jG3cFPNBiN3_0YZVhvwTgs2xpmf4

Log file n/a

Additional information Simplify3D makes the same mistake FWIW. This sounds like a fun bug to swat, and should have dramatic effects on the quality of everyone's output when fixed.

Note Do not tell me to use supports - this is a bug about obvious misbehaviour when supports are not in use - the bug needs to be fixed, not worked around.

[gitcnd]

If anyone who knows the code wants me to fix this, point me at the exact place the fix needs to go, and I'll take a shot. I'm good at these kinds of algos... (but too busy to wade through it all and learn where it needs to go)

[smartavionics]

Let me save you some effort, install a release from https://github.com/smartavionics/Cura/releases and then enable the remove holes above air setting...

If you try it out and have any problems, please open an issue at smartavionics/Cura rather than here.

[gitcnd]

Cool idea... except of course that the holes got removed.

I also noticed a second bug when trying to emulate that same behaviour in 4.8 - it selected the lengthwise direction for making the bridges, but the shorter breadthwise one would have been the more correct one to select.

The code needs to create angular bridges that are tangential to the holes, not cover them over. It should do that a sensible number of times for the size of the holes in question (e.g. 8 times).

[gitcnd]

Like the blue lines here:-

(although probably connected to the lines, instead of going over existing ones etc)

[gitcnd]

And, while on the topic, it probably shouldn't decide that the holes need to be printed first and separately from the layer fill - if it had done all the fill lines it could first, then at least if it did the holes at the end, there would be some material for them to connect with...

[Ghostkeeper]

This is not a bug. It's behaving as expected. Perhaps not as you desire, but it's not expected to do anything special in this case; it's just going to produce the correct amount of walls to surround those holes as the setting instructs it to, and the skin lines are interrupted by those walls. If it didn't do that, I'd consider that a bug. So this is really a feature request.

The proposed solution will not work for the arbitrary case though. It can't work for shapes which are not convex. Perhaps clearest to see with an example (same sort of colour scheme as what you were using):

It's simple enough for a human to think of a way to stagger lines such that it'll kind of work for your shape, but an algorithm has to make it work for every shape. And in some cases there just is no solution that does not make lines hang in mid-air.

[gitcnd]

Yeah, it's a bug. Exactly zero people in the universe (excluding you) think that pointlessly squirting plastic into thin air is "expected behavior", when "It's simple enough for a human to think of a way to stagger lines such that it'll work". If you're not a good programmer - do not comment on things you don't know how to solve - LEAST OF ALL when the person who made the report IS a good programmer, who already offered to code this fix...

[Ghostkeeper]

Well, you are free to experiment, of course. I'm just predicting that there will be lots of cases in which your suggestion doesn't work. I'd love to be proven wrong! But I don't see how your suggestion would apply to the shape I drew above (filling the lightest red area with straight lines that rest only on the pure red areas).

No need to take this personally, please.

[tyeth]

I've got further bugginess to show, easy reproduction case. It's actually ignoring the wall constraints. I set the wall count to be 5, this gets reduced (to 3/4 depending on my line width - a 0.4mm nozzle) where the wall is actually thinner than 5xLINE_WIDTH. When it gets to the bridge layer it goes and increases the wall count to 5 regardless and then patterns the bridge layer inside that 5th wall which is itself also over mid-air.

I'm recreating a simple cylinder birdfeeder, it's 200mm x 64mm with an open top, 1.5mm thick with a 6m space at the bottom before a 2mm nested "base". I ambitiously thought I could go high speed printing and bridge that with no support in PETG (still experimenting with this roll), but it fails due to mid-air printing instead of tacking each line (a small amount of overlap at least).

I've attached the STL, FreeCAD project, cura project and gcode. Analysed using https://gcode.ws/ S2A_birdfeeder200x64x45hole-bridge.zip

I've attached the STL, FreeCAD project, cura project and gcode. Analysed using https://gcode.ws/

[Ghostkeeper]

I've got further bugginess to show, easy reproduction case. It's actually ignoring the wall constraints. I set the wall count to be 5, this gets reduced (to 3/4 depending on my line width - a 0.4mm nozzle) where the wall is actually thinner than 5xLINE_WIDTH.

This is because your model has a width of 1.5mm there. Printing an 1.5mm wide part with 0.4mm line width results in 2 walls from both sides (centrelines at 0.2mm and 0.6mm away from the side). More lines wouldn't fit. This is expected behaviour, and unrelated to the feature requested in this ticket. If you want the model to be thicker, it should be edited in CAD or by Horizontal Expansion in Cura.

When it gets to the bridge layer it goes and increases the wall count to 5 regardless and then patterns the bridge layer inside that 5th wall which is itself also over mid-air.

On the bridge layer there is enough width to print all 5 walls. As per the setting "Outer Before Inner Walls" being disabled, it should print the inner walls first, so it's going from the innermost wall (which is overhanging) to the outermost wall. It then attaches all lines to the innermost wall as expected. You have the Skin Overlap set to 5%, so it's going to overlap the skin lines by 0.02mm with the adjacent wall.

What would you change to make this print better? What is your expected behaviour, if that can't be achieved by changing settings?

[tyeth]

Thanks for the quality reply!

I don't have the cad model, but do appreciate designing to line width is the way to make good prints/parts. I have a 0.4mm nozzle so could do 0.2mm-0.6mm going by the settings guide plugin, should I always be varying across this full range to fill models with enough distributed walls or is it better for adhesion to stay near 0.4?

Expected behaviour is the first layer of bridge would not provide the slicer with available model space of the full walls plus bridge area but infact the layer beneath, I.e. just the walls space, the additional model space on the current layer is a bridging space done as a first slow layer. Then at layer2 of the bridge it should be stable enough to respect wall line count and the slicer should be allowed to put the full wall count instead of areas of the bridge.

I also expect "Outer before inner walls" to not mean force a certain inner wall order as in this instance this created an inner wall line in mid-air rather than an offset stacked or horizontally joined wall or the expected bridge.

[Ghostkeeper]

should I always be varying across this full range to fill models with enough distributed walls or is it better for adhesion to stay near 0.4?

Closer to 0.4mm is better for the flow rate. You're less likely to get underextrusion or overextrusion in your print then. I won't go too deep into the line width optimisation here since it's off-topic.

So if I understood well, you'd want it to produce walls only in the space where it's not bridging, and make the overhang 100% using the skin pattern? That would mean interrupting the walls though, which is not going to be nice for the constant flow of materials. It does make bridging a lot simpler to understand for the user, which is a bonus (especially by not having all of those wall bridging settings).