Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Splitting the straight lines on perimeter #703

Closed
angar79 opened this issue Sep 18, 2012 · 5 comments
Closed

Splitting the straight lines on perimeter #703

angar79 opened this issue Sep 18, 2012 · 5 comments

Comments

@angar79
Copy link

angar79 commented Sep 18, 2012

I am found the fact that a straight line for some reason splitted into several colinear parts. This cause extrusion into several stages mixed with zero movement vectors. Splitting takes place at the border triangle of the triangular mechanics!

STL in SolidWorks:
STL in SolidWorks
Builded model:
Builded model
Layer 0 in Skeinforge(g-code builded in Slic3r):
Layer0
Layer 7 in Skeinforge(g-code builded in Slic3r):
Layer7
Repetier-Host:
From repetier-host

Slic3r version 0.9.2
Config
STL-model
OS Windows 7 Professional x64

@angar79
Copy link
Author

angar79 commented Sep 18, 2012

Btw, I have no this problem with Slic3r 0.7.2b

@mesheldrake
Copy link
Collaborator

This is similar to issues #700 and #702, because turning up the scale number in offset() mostly fixes the problem, but again, not completely.

These animations come from me clicking on different layers of the toolpath, to highlight individual moves. In the first one you see several short segments, essentially reproducing angar79's issue. In the second image, I've set scale=1000, and the same process reveals that the straight paths are single moves - mostly.

offset scale = 1
straight paths broken up at scale=1

offset scale = 1000
straight paths mostly not broken up at scale=1000

OhmEye says the scale=1000 fix causes problems for other STLs though. And I thought setting scale large enough would get rid of these artifacts completely, but small ones persist. So setting scale isn't the only issue.

@mesheldrake
Copy link
Collaborator

Fixed the last few broken lines from last test case by setting scale for the safety_offset() function to 10000, matching that of the offset() function. See #702 for code. Result: no more fragmented straight movements here

no more broken lines here

markspace pushed a commit to markspace/Slic3r that referenced this issue Sep 22, 2012
A default scale of 1 was being calculated most of the time. That's too
low to avoid artifacts from offsetting concave curves. Setting scale to
a default of 100000 eliminates artifacts in the test cases in issues
slic3r#700, slic3r#702 and slic3r#703. There is a risk of large point proliferation with
this scale in combination with the JT_ROUND option, but in the four
places where that option is used, scale is already explicitly set to a
safer low value.
@alranel
Copy link
Member

alranel commented Feb 27, 2013

@angar79, collinear paths should not be visible in the printed object. We've been getting some complaints from people about Slic3r "oversimplifying" the geometries (even by 0.02mm or something like that), so the strong choice was made to almost keep the original data without any decimation.

Still, any modern firmware should just print collinear paths as single movements. What firmware are you using, and what did you use to make that picture?

@alranel
Copy link
Member

alranel commented Mar 30, 2013

This is related to #772

@angar79 angar79 closed this as completed Dec 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants