Curaengine: Combing mode all bug

Created on 12 Oct 2017 · 13Comments · Source: Ultimaker/CuraEngine

Let's play spot the difference!

screenshot_2017-10-12_08-53-02

screenshot_2017-10-12_08-53-48

Not so hard, was it? The upper image shows the results of combing when mode is set to all which computes the combing boundary based on the centre line of either the 2nd or 1st wall.

The lower image shows what you get when the combing boundary is shrunk by 10 uM.

The travel that is crossing the hole is moving from a point on the 2nd wall to another point on the second wall but because both points are actually on the (unshrunk) combing boundary it fails. By shrinking the boundary by 10uM, the start/destination points fall outside of the combing area and the combing does the right thing.

My fix to LayerPlan::computeCombBoundaryInside() looks like this:

            Polygons temp;
            layer.getSecondOrInnermostWalls(temp);
            comb_boundary.add(temp.offset(-10));

Shall I submit this as a PR or is there a bug in the combing code that could be fixed to prevent this occurring?

bug deferred

Source

smartavionics

All 13 comments

IIRC, there's already two "combing boundaries" in the current implementation, one that it has to avoid and one that it uses for inside checks, precisely for this reason. Adding that fix would only introduce an unnecessary polygon and inset which should already be performed.

Ghostkeeper on 20 Oct 2017

I'm not seeing the bug myself though. How should I reproduce this? Does it only happen on that model?

Ghostkeeper on 20 Oct 2017

My guess is that you need the situation where the start and end points are both exactly on the combing boundary. Maybe it also needs to cross air as well? I have only seen it on this model.

smartavionics on 20 Oct 2017

Looks like the same issue... https://github.com/Ultimaker/Cura/issues/2683

smartavionics on 26 Oct 2017

In https://github.com/Ultimaker/Cura/issues/2785 we found some reproduce steps for this one: Load the model in this zip into default UM3 settings: Tube.zip. This doesn't give the bug. But when you scale the model to 110%, the combing suddenly fails.

Ghostkeeper on 5 Dec 2017

OK, perhaps you would care to try the fix I show above and see if that also fixes this latest example?

smartavionics on 5 Dec 2017

Even if you don't want to fix the problem using that code at least that would confirm that it is the same bug.

smartavionics on 5 Dec 2017

This could be a related problem https://ultimaker.com/en/community/52344-unwanted-lines-on-surface

What's happening there is that while printing the walls of the legend (220 V) it's travelling across the red region retracted but not z-hopped even though z-hops are used for some other moves. It looks like the combing code is quite happy to move in a straight line over the region that should have been avoided.

PS - I still think that the combing code should have the option to do z-hops and not just retracts, why does it not do that?

smartavionics on 11 Dec 2017

Cura's project manager removed this from our planning because it wasn't deemed important enough.

Ghostkeeper on 21 Feb 2018

What a surprise? It's pathetic that you have numerous long standing gcode quality issues that are simply ignored while countless hours are spent on creating glitzy "fashion features". Well, I don't give a flying fuck anymore, I shall simply fix the problems that I can in my own code base and not bother to submit any more bug fixes.

smartavionics on 21 Feb 2018

😕2

Yeah, I think we should reduce the number of front-end features and I keep saying that at the planning meetings as well, but it's pressure from higher up... You know that we had a refactor planned for the engine for last November, but it keeps getting pushed back further and further because nobody seems to care about the engine any more down here.

Issues like these may still get picked up if they are also found by our Materials & Processing team. Otherwise, I'm not giving them a lot of chance...

Ghostkeeper on 21 Feb 2018

I know how depressing it might seem when you are contributing a lot and helping fix a lot of problems in the engine, but they aren't really picked up.

I had this very frustration built up over 3 years. The reality is that not all issues can be handled. I wanted to do every improvement I thought about and I didn't care about the frontend as much.

Over time I realized that those frontend features were also quite important. Of course there have been features which weren't as important in hindsight, but there are still quite some important frontend features. I wouldn't classify them as fashion features.

Still I think the engine is of utmost importance to Cura and we should spend at least a third of our resources on it, but that's just how I would divide the resources.

Also you might be underestimating how much time it takes to handle an issue. The implementation takes a small amount of time compared to reviewing, testing, understanding, explaining, discussing etc.