Skip to content


Incorrect "corners" Due to Merging Points and/or Collapsing Edges #801

cakeller98 opened this Issue · 21 comments

3 participants


Features smaller than 0.2 mm with multiple vertices seem to collaps and move. they don't seem to move to the average of their center, but rather move inward away from the perimeter, or sometimes slide around the perimeter.

Here is an image with a snub-nosed part, see how the converging triangles cause the gcode output to move around at the tip... not even at a singular point or an implied flat, but randomly. that face - is vertcal and should not be moving in Y, only getting wider/narrower in X

Image showing movement

I found this the easiest way to view it is with video:

Quick Video showing the layers, and the STL file

the files I used are:

Config.ini File

STL file

GCODE Output from commit ac5be309e398e29c8382da5c0c6e26da3163bf62

UPDATE 2012/11/19:

Simplified STL

new more simplified model has the following problems: 1) rear corner appears to be treated as a thin wall once it reaches a specific aspect ratio and small size. 2) the front corner appears to be merging points once they get close enough which alters the perimeter more than would be nice.

Here is output from slic3r --debug (this is why I think it's a thin wall)

Making surfaces for layer 0 (slice z = 0.100000):
Discovered ccw polygon of 8 points
1 surface(s) having 0 holes detected from 1 polylines
3 thin walls detected
Making surfaces for layer 1 (slice z = 0.287500):
Discovered ccw polygon of 8 points
1 surface(s) having 0 holes detected from 1 polylines
3 thin walls detected
Making surfaces for layer 2 (slice z = 0.462500):
Discovered ccw polygon of 8 points
1 surface(s) having 0 holes detected from 1 polylines
3 thin walls detected
Making surfaces for layer 3 (slice z = 0.637500):
Discovered ccw polygon of 8 points
1 surface(s) having 0 holes detected from 1 polylines
3 thin walls detected
Making surfaces for layer 4 (slice z = 0.812500):
Discovered ccw polygon of 8 points
1 surface(s) having 0 holes detected from 1 polylines
3 thin walls detected
Making surfaces for layer 5 (slice z = 0.987500):
Discovered ccw polygon of 8 points
1 surface(s) having 0 holes detected from 1 polylines
Making surfaces for layer 6 (slice z = 1.162500):
Discovered ccw polygon of 8 points
1 surface(s) having 0 holes detected from 1 polylines

Here is an overlay of the gcode to the stl file. shows clearly the end of the rear sharp corner is getting converted to a thin wall, and then that thin wall is lookin' icky. also the front corner is flat in the model (see above) and near the bottom as the thin triangle gets wider and the wider front triangle gets narrower, the right corner merges once it gets within a small enough limit. this is a problem because it makes the long angled side look crappy when printed.

Top Down View

3D view of the same issue - please note the filament thickness is -.1 (tiny) for easier visualization. this is why the paths are offset from the surface, and doesn't appear to fill the stl, but in reality it would.

lower right is the "thin wall" issue, bottom front is the "point merging" issue.

3D view

STL file for download: Simplified STL File

GCode file for download: GCode for above - no infill


Per your request - here is the chat:
Hey Sound, :)
I did a bunch of testing on that issue, and have a couple questions...
cakeller98: tell me
1) do you bevel sharp corners?
cakeller98: I don't know
and - 2) what's the hatching that happens on the inside of accute angled corners?
I don't know again :D
ok lemme put up a picture
remember to attach everything to the github issue
cakeller98: is it like a pile of dots?
3) I'm seeing these detached points beyond the ends
cakeller98: that's a clipper issue, I think it was fixed recently?
also, I'm not sure I understood the report on github
perhaps a picture showing what would you expect could be helpful
this is related to that issue
but the point is - clipper is erroneously MOVING points that I don't think it should
that's an assumption - I'd prefer you show what happens and what you'd expect
Good point - I'm overlaying the model and gcode in photoshop top-down so you can see how obviously the points are bing moved on these small features.
Sound, and the super wierd extra crap that's beyond the top of the points
thank you
atatch that to the gh issue
will do - and actually I just figured out how to load STLs and GCODE into Repetier Host :) (hehe... never sliced with the RH interface)
*I never sliced with...
Sound, please look at this and tell me if this shows what I'm talking about
cakeller98: ah, those little dots at bottom right?
note - the filament is thinner than real, so it looks offset from the object, but you can see in the bottom 5 layers, there's a problem on the right corner, but also if you look closely, there's a problem on the front corner in the bottom 8 layers
so yes, the dots - were a surprise, but the front corner's 8 bottom layers have the right corner of that front face merging and pushing forward with that diagonal edge
isn't that in the model?
the front face is made of the 2 triangles (thin one, and the one that gets wider toward the top) the right edge of the thin triangle appears to be merging with the right egdge of the wider triangle in the bottom 8 layers as the edges get within 0.1mm of each other.
it is not in the model - that front face is flat
can you guesstimate the amount of the error in mm?
2 co-planar triangles, yes 0.05mm but it causes flat surfaces to look wobbly
if you look at the bottom of the object - there is a horizontal line (base of the skinny triangle) that is exactly 0.1mm wide
it actually appears to be merging up to about 0.15mm, maybe even 0.2mm (layer height is 0.175, perhaps that is the dimension it's related to? or half my nozzle diameter (0.345mm)
can you put all this info in the gh issue?
even a copy and paste of the IRC transcript
I will have mesheldrake investigate that


More info about the single wall thicknesses and the "stitching"

grid showing what happens with thinner and thinner walls from 2.0 mm down to 0.32 mm (0.345mm nozzle, 0.1mm layer height, no infill, 1 perimeter (no generated extras)


grid showing what happens with thinner and thinner lines

Note - the single-wall, you'll have to zoom in to see the ACTUAL gcode path ...


Impressive documentation you supplied here. Thank you.
I think I know what's happening in that corner...


@cakeller98, I pushed a commit that should fix the corner issue. Can you test it?
@mesheldrake, I raised offset miterLimit from delta = 2 to 10. Do you think it's a good value?


@cakeller98, Really like that test case illustration. Thanks for doing that.
@alexrj, seems like there's some risk of creating sliver artifacts if a narrow but squared off or rounded off corner gets inset to a sharp point, then outset with a miter limit that doesn't happen to correspondto the original squared/rounded off geometry. The sliver might "puncture" through that and trigger a false short thin wall at the point. i need to make a test case for the medial axis/dynamic flow stuff, so I'll add in some narrow points with squared and rounded tips to test this.


@mesheldrake, do you think the original model was squared itself? It looks more like the effect of miterLimit in the first offset. I wonder whether @cakeller98 had a chance to test the failing model to check how does it render now that I raised the miterLimit.

Also, how is this related to medial axis?


@alexrj the first test case was a trapezoid that almost becomes a triangle at the bottom. that flat face survives without being merged down to a really tiny size.

the actual accute angle (upper right) that has the point and ends up with the garbage punching through was fixed (for this test case)

for the "dog-bone" test, the problems actually start to increase. there are still cases where "extra" geometry outside the model is being created.

@alexrj @mesheldrake - could there be an easy solution to this, by simply checking point validity? - if the points are not INSIDE the original shape cull them? - probably way harder to do in practice. Also it would hide the problem, rather than improve the algorithm.

I will post an updated picture of the dog-bone slice as soon as I can.

OK this one shows, there's a specific point where the "thin wall" detection appears to be detecting thin walls, but having a math error which causes the outside-of-model garbage.


As you can see in the 4th row from the bottom the pair of extraneous lines in the middle 2 shapes. but also, disturbing are the > and < at the ends of the "thin wall" that make the thin wall which should simply connect the two sides with a line, end up detached and with the > < at the ends, like this: >---<

Also, I don't understand the strange "stitching" that starts with the upper right one, and doesn't end until the first in the 5th row down. basically it works out to <4 perimeters thick and >2 perimeters thick will get this stitching.

hope this helps... when I get back to this, I'll do a test-case model and reference illustration explaining the details and dimensions.

It's only a single layer thick, so I can also do some illustration of what is "expected" though mostly, I think it's obvious.

it almost appears that right below where it's obviously not thin wall and above where it obviously IS thin wall, there seems to be this width that ends up with some crazy math error pushing some number to go inverted which then causes a bad offset.

good luck, and I will post more later.


Thin walls are filled by the current Math::Geometry::Voronoi-based medial axis code. I'm guessing the "out of bounds" paths in the dogbone tests above are coming from that. (Those could be new Clipper artifacts, but the >--< shape on the last 13 dogbones is typical of a rectangle's medial axis.) Before your miter limit change, sharp points were also generally filled separately (with current medial axis code) as thin wall fragments, which was the cause of the main complaint in #708.

I've been using #708 as a new medial axis test case, because it's got both those thin wall sharp tips and thin gaps of various sizes to fill.

Since you turned up the miter limit, there are almost no thin wall sharp tips on that model. Not sure if that's good though. Miter limit should probably be set relative to extrusion with, to keep the extrusion from doubling back on itself in a sharp corner. A miter limit of one, which is probably the same as jtSquare, seems like the safest value for avoiding overlap, but in practice 2+ might work fine. 10 seems high, but we would need to look at what happens with each offset step to see if maybe that ends up being safe even in very sharp corners. The best way to figure miter limit might just be pointy object print tests with different values.

I'm guessing a bit of self overlap in sharp corners is better than doing all those sharp tips as separate short thin wall segments.


@mesheldrake Well the extrusion diameter is a good limiting metric for actual feature size, as long as the simplification doesn't think "oh, no problem, I'll merge these points because it will be within that radius. even a 0.05mm shift of the end point of a wall segment will cause that wall to have a visibly non-flat surface look.

thin walls should be at least 3 extrusion diameters long perhaps.

medial axis having the > and < at the ends is wrong for printing purposes, no matter if it is the "medial axis" of said rectangle. a wiggle at the ends would make sense (though I get that that would require an algorithm) but having those > < that are (1) detached from and 2) outside of the model isn't a very nice solution.

I can modify the model so it has star-like points on one end, a thin wall, and a round end if that would help.

@mesheldrake mesheldrake pushed a commit that referenced this issue
Mike Sheldrake set miterLimit to 3 - compromise between 2 and 10 #801 fef5709

working on it

Here's the test shape i've been working with for thin walls and tips.

On the left is current behavior. On the right the stuff I'm getting with the medial-MGD branch.

Somewhere in between those two images is what we need.

The thick gray lines are one extrusion width along the outer perimeter.
The dashed lines are the model boundaries.
Red is the thin fill path, based on the medial axis approximation. The pink halo around it is the expected extrusion width.

These are frames of these videos, which show behavior as the thin areas get thinner.
(Turn on HD quality and go full screen if you watch them.)

current thin fill
dev thin fill

Here are the SVG sources of the two PNGs above, if you want a closer look.

master svg
MGD svg


you need to have a few sizes of "thin-walls" a single wall, a 1.3, 1.7, 2, 2.3, 2.7, 3, 3.3, 3.7, and 4

why? because there's a bunch of weird stuff that happens when there are less than 4 wall widths.

the spikes you've got there though, those seem a decent test case.

what would happen if you traced ALL outter perimeters and then did an overlap detection - just for these? in other words... in the case of the almost single wall thickness, you generate paths for both sides and overlap them. paint the first one, then paint the second one only where the first one doesn't exist yet? IOW only paint where there's no paint yet.


I was skipping the test case for > 2 extrusion widths because that's handled by a different part of the code. Your tests triggered both thin walls and thin gaps, and I'm looking at both situations, but the more challenging case is < 2 extrusion widths thin walls. And I included thin points because your original model's problems have to do with the combination of miter limit and thin wall/point filling.

I see what you mean with the paint analogy. The challenge is that the perimeters aren't generated in a linear paint-like way. The tools at hand don't suggest that approach as the obvious one, but we may coerce them into doing something similar to what you describe.


I just love the pictures that you both @cakeller98 and @mesheldrake posted here, and related discussion. Thank you!
I look forward for merging the medial-MGD branch.


Linking this issue to commit 68fc91d (miterLimit = 3); attaching this issue to the next milestone as the proper fix involves the merging of medial-MGD.

@alexrj alexrj modified the milestone: 1.1.2, After 1.0.0

After all the work on the medial axis code that took place in the last month, I believe this issue can be closed successfully. However I would like to test with the test objects used in here before closing.

@cakeller98, can you point me to the dog-bone object you used for the pictures above? Thanks for helping!

@alexrj alexrj removed this from the 1.1.2 milestone

Thank you!

This is how Slic3r 1.1.x processes that file, thanks to linear gap fill and dynamic variable-width gap fill:

schermata 2014-04-30 a 15 30 21
schermata 2014-04-30 a 15 30 14

I like happy endings ;)

@alexrj alexrj closed this
@alexrj alexrj added this to the 1.1.2 milestone

Looks great - Congrats!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.