seam : nearest no near enough.

[supermerill]

Version 1.41.1-1 of my fork, equivalent to your 1.41.1

Behavior

When slicing for a printer with a big nozzle, we want to avoid ooze as much as posisble, so reducing travel as much as possible.

Currently, no seam option allow to reduce the travel at all cost.

(note: this picture is a bit falsified as i used a special process that create many sharp angles in perimeters)

I see that the last_pos_weight in gcode.cpp:~1950 is only at 1 with spNearest.
So I changed it to 5 and created an other option that let it to 1.
That way, nearest can reduce drastically the travel needs (useful for preventing ooze if needed)

It's because the delta between "best seam angle" and "good seam angle" is 1 and so it's impossible to go to a good near solution if a very far away bets position is available.

Also, i didn't understand the
"// Give a negative penalty for points close to the last point or the prefered seam location."
block of code a bit below in gcode.cpp so i replaced it by
"penalty += last_pos_weight * polygon.points[i].distance_to(last_pos_proj) / dist_max;"
with dist_max = maximum distance between the last_pos_proj and any point in polygon.

[bubnikv]

@supermerill did you get the current master to compile?

[DrLex0]

I have also noticed that ‘nearest’ is often not nearest at all. At other times it is too near and selects horrible starting points while a much better point is only a few mm farther away. Attached is one of the worst examples of both shortcomings, generated by 1.41.2. (Print settings can be extracted from the gcode file, but the only real important setting is that seam position is ‘nearest’.)
ClipTest.zip

All the awkwardness can already be seen in the first layer: the inner contour starts on a convex corner even though a concave corner is just a few mm further away. For the first layer this isn't important but it again happens on layer 3. There seems to be too much emphasis on ‘nearest’ in this case.

Then after completing this first contour, a travel move is made across the entire model in order to start from the farthest possible concave corner. I have no idea why the ‘nearest’ aspect is completely ignored in this case.

This weird huge travel move is obviously a bug and should be fixed, but then the problem remains of subpar starting points being chosen just because they're somewhat closer. Ideally the travel distance penalty factor should be configurable, or there should be an additional seam position option (called “best” or so) that emphasizes starting point quality over travel distance.

[DrLex0]

Here is another nice example. NotNearest.3mf.zip

Even though seam is set to nearest, for some reason each layer in the entire middle section of the object always starts with a long travel move back to the same starting point as if I had selected ‘aligned.’ There is a much nearer corner of exactly the same concavity, why is it ignored?

And it gets worse:

Not only do these long travel moves increase print time, they also caused this model to be printed ugly. In the last shown example the move is not retracted because it follows the contour of the slanted wall. The PETG I've printed this in is prone to oozing, and this long move causes a streak of ooze to be deposited on the wall. This eventually accumulates and is pushed beyond the outer perimeter where it leaves an ugly blob. (I should have taken a photo but this was a part I had to print urgently for someone else. Luckily it didn't need to look nice.)

I think I have found the commit that has introduced this behaviour, it was 82aed45 from 2 years ago. In GCode.cpp extra logic was introduced that is applied regardless of the seam position option. There is an if statement for ‘spAligned’, but it is commented out. The logic causes positions near the previous layer starting point to be preferred, in other words the other seam position options become very similar to ‘aligned’. It defeats the ‘nearest’ concept.
I would like that if statement to be re-enabled, perhaps changed to if (seam_position == spAligned || seam_position == spRear), but not spNearest (nor spRandom, but it is handled separately anyway).

I guess I'll be forking the code and making this one-line pull request unless someone who already has a fork does it.

[DrLex0]

The commit I mentioned in my previous comment was not to blame, what it does is selecting the point on the contour closest to the previous position if this point scores only marginally worse than the best corner point on the contour. This makes sense especially for the ‘nearest’ criterion.

I have dug further and noticed that the code didn't even try to minimize travel distance. I have looked at @supermerill's suggestions above, and they make sense. I have implemented them, tested them on a bunch of prints, and made pull request #2222.

[bubnikv]

Seam placement will be improved in PrusaSlicer 2.3.0-alpha1. Closing.