Aligned or nearest seam position on convex vertex when a concave non overhang vertex available

[dartrax]

Version

19ea7a5

Operating system type + version

Win 7 64bit

Behavior

slicer not always uses concave non overhang vertex for start/end point of outer perimeter.
In this example, seam position is "nearest" and the concav vertex inside is not overhanging, I do not see why slic3r doesn't use it.
In general, I'd find it useful to specify the seam position as nearest to some Point (X, Y) like in S3D. We print half shells and the inside is hidden, so it would be perfect to have the seam at the inside. This is not achievable with "rear" setting. But it may be best to open a feature request for that... ;-)

[dartrax]

I tried to investigate that further in order to provide a simple example showing the issue.

This is the resulting gcode, seam position setting "nearest":

What happens?

On the left: Slicer does not use the concav vertex where the seam would be less visible. It uses a convex vertex.
On the right: Slicer does not use any vertex at all, it puts the seam on a rounded surface.

What is expected?

Slicer should use the concave vertex in both cases. Help file says about "nearest":

This will try to choose a concave non-overhang vertex so that the seam is hidden in the inside of the concave angle. If no concave non-overhang vertices are available, it will choose a convex non-overhang vertex. If none are available, it will choose a non-overhang vertex. The choice among the candidates is operated so that the start point is the nearest to the previous extruder position. So this option will optimize for short travels.

Slicer seems to ignore the vertex because the angle is higher than 120° (in the example, it is 120.1°). But I think the concav vertex should still be preferred over the convex vertex and the convex vertex should always be preferred over a otherwise smooth surface.

STL.zip

[bubnikv]

I wonder how the Slic3r Prusa Edition would compare to the upstream Slic3r in this regard. The Slic3r PE implements a somehow different heuristics, and it also tries to avoid overhangs.

[dartrax]

Hi bubnikv,
thanks for the suggestion, I just tried it out. Result with SlicerPE:

I also peaked into the code.
First, slicer: Slicer simply searches for vertices that are either greater than Pi * 4/3 (= 240°) for concave vertices or smaller than Pi * 2/3 (= 120°) for convex vertices. This is hardcoded in GCode.cpp.
So this can be fixed easily, we just need to discuss/decide for better limits here.

Now, what is SlicerPE doing?
SlicerPE calculates penalty points for each point in the polygon of every layer. Concave vertices with angles smaller than -0.6 * Pi (-108°) get a score of 0 penalty, convex vertices greater than +0.6 * pi (+108°) get a score of 1 penalty, and if the angle is zero (flat surface), it gets a score of 5. Everything between gets B-Spline interpolated.
Points that are overhanging more than half the nozzle diameter get a penalty of 10 added on top.
After that, points that are close to the last point (or the prefered seam location? seems easy to get implemented here - and I took the challenge for SlicerPE here) get a bonus - but I could not figure out the value right now. Here's the code.

So in the end the concave vertices should get a penalty of nearly 0, because the angle of 120.1° is just slightly greater than 108°. The convex vertice will get a penalty of nearly 1, because the angle of 90° is slightly smaller than 108°. But because the convex vertice is nearer to the last point, it gets enough bonus to win over the concave vertice.
This is something I would like to have a setting for, so that I can decide that the use of the concave vertice is more important to me than the saved travel time, but that's a SlicerPE-topic not to be discussed here.

We should discuss if we should change the limits of slicers vertice recognition or if it wouldn't be better to follow PrusaPE's approach of the penalty model. That would also allow for implementing a preferred seam location (requested in #2911) by coordinates.

Edit: Added Reference to SlicerPE Feature Request #342 and Pull Request #728.

[lordofhyphens]

I'd be happy to accept a PR if you want to take a swing at implementing better seam placement in Slic3r.

[dartrax]

Thank you for that offer.
Currently I use and contribute to SlicerPE, and because I'm a git-noob with too less time I fear can't contribute to both projects...