Incorrect "corners" Due to Merging Points and/or Collapsing Edges #801
Comments
|
Per your request - here is the chat: |
|
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) DIMENSION SHOWN IS THE WIDTH MODEL WALL WIDTH.
Note - the single-wall, you'll have to zoom in to see the ACTUAL gcode path ... |
|
Impressive documentation you supplied here. Thank you. |
|
@cakeller98, I pushed a commit that should fix the corner issue. Can you test it? |
|
Will test and get back to you |
|
@cakeller98, Really like that test case illustration. Thanks for doing that. |
|
@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. |
|
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. These are frames of these videos, which show behavior as the thin areas get thinner. current thin fill Here are the SVG sources of the two PNGs above, if you want a closer look. |
|
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! |
|
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. |
|
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! |
|
Ok On Wednesday, April 30, 2014, Alessandro Ranellucci <
--- Chris |
|
Dog-Bone Shaped Test Part (Varied thin-wall) STL PART from https://github.com/cakeller98/Cakeller98Postings.git hopefully the direct link to that STL should be enough. --- Chris On Wed, Apr 30, 2014 at 2:20 AM, Chris Keller cakeller98@gmail.com wrote:
|
|
Thank you! This is how Slic3r 1.1.x processes that file, thanks to linear gap fill and dynamic variable-width gap fill:
I like happy endings ;) |
|
Looks great - Congrats! |
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
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:
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
....etc
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.
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.
STL file for download: Simplified STL File
GCode file for download: GCode for above - no infill
The text was updated successfully, but these errors were encountered: