Fix polyline handling #1362
Fix polyline handling #1362
Conversation
alter the simplify function to also work on polylines make the original function private and create some indirection, so that no programmer can accidentally call the wrong simplify on a polygon / polyline object
it doesn't make sense to chain together polylines if they are so far away
also applies wipe correctly to a whole chained line
generated polyliens used to be cut up into single line segment polylines, because we weren't able to process longer polylines Now we are able to process longer polylines, so we directly put generated polylines into the result_polylines
when there are colinear line segments within the same polyline, clipper produces extraneous or missing segments in the result of an intersection clipping operation.
it was implemented double and made use of home grown functions rather than built in functionality
clipper doesnt handle polylines well when they are longer than single segments, so we split polylines into segments before calling intersectionPolylines always stitch polylines after intersection
polygons aren't guaranteed to represent correct areas. Arbitrary zigzagged patterns can be connected into polygons which violate the even-odd rule
because of the zig-zag econnections walking along the outline of the polygon, there might be overextrusion there. The worse case scenario is a long polyon which fits one infill line, but also has a zig-zag connector running along the legnth of the polygon at nearly the same location as the infill line.
It's now performed in a separate function
It's better to keep the code for extra security
An extruder which was only used to print a surface mode mesh wasnt marked as being used, which resulted in the mesh not being processed and thus not printed.
when the outer wall extruder was set to something different than extruder selected for the surface mesh, the mesh would be printed using both extruders, but an assertion would fail.
limit the open polylines and closed polygons to the infill area of the other meshes
|
Slice time can reduce drastically, depending on the model. UM3_armadillo_Deform__support.3mf.rename.zip Uploading UM3_dragon_65__support.3mf.rename.zip… UM3_jet_engine_part.3mf.rename.zip For surface mode it's a more clear advantage |
|
See above three linked PRs for more example results. |
BagelOrb
force-pushed
the
all_polyline_fixes
branch
from
4e47dc3
to
8c8044a
Compare
|
Has this been abandoned? These features would be so helpful for me... |
|
Yeah, this was sort of abandoned in favour of Arachne (#1210). We are unsure if there are still pieces of this that we now need to merge in. There's a lot of changes here though so it's hard to say. |
The part that I'm most interested in is correctly handling polylines for surface mode. Currently, surface mode doesn't respect some settings like resolution, so if the mesh is highly detailed, the prints take a long time because the polyline created from slicing has tons of tiny line segments. Sometimes the print order of the polylines is odd too. Like starting in the middle of what should be one long line segment. I'm not sure if Arachne handles those cases or not. If so, great! |
This PR combines the past few PRs of mine which ar all related to processing polylines.
This concerns polylines in surface mode, but also for all infill patterns.
As such this PR has the following advantages:
simplifyPolylines()removes verts, which removes the need to slow down for a corner there. )PS: the zigzag order bug I recall: Left infill line is printed first, right one last.
