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
Objects (with very tiny clearances) which should be kept separate are connected. #1056
Comments
Same issue as #959? If the distance is somewhere between 0.3mm or less, it seems slic3r just fills in the space. |
Clearly this is the same issue as #959. Altering Layer::Region::_merge_loops() as follows resolves the issue for this model. $safety_offset //= scale 0.04; |
@Lodran, what happens if you "split" the object, so they are actually separate objects in plater? do you still have the merging problem? since these parts all lie on the ground plane, they won't shift, and in my tests they don't merge... I think the merging only happens within a single object. @alexrj, does the union/diff step have to happen before contracting the objects back to their original size? is there an alternative that doesn't eliminate overlaps? |
splitting the objects also works around this issue, at least for this model. |
I set the offset to 0.0499 as proposed by @mesheldrake, can you confirm current git works? |
@alexrj, this is great for objects like the aligator, but for objects with truly separate perimeters, why do you have to merge them in the first place? why are you trying to merge these islands? I see in the code, you do the following (unless I'm wrong) offset, which in theory should give you the same shapes as the original, unless there is some overlap, in which case union will merge objects. what is the purpose of the union? - if the logic is that you want to get rid of small holes/gaps, then I guess it's doing what you want... but if the safety offset serves another purpose, then why not offset, -offset, union eliminating the worry of the safety offset overlap? I basically disagree with the idea that we have to eliminate slots/gaps etc... though if there is a good reason that I'm missing, at least 0.1mm is small enough that it's probably reasonably small enough to not matter. as you said - you are trying to make software that prints exactly what it's supposed to, so if there's a 0.05mm gap, you're eliminating it, and that's not sticking to your edict. |
I can confirm that the gear bearing does slice properly now with no inter-connected gears on any of the gcode layers. I have attached my output gcode to confirm. My settings are not the same as the settings used when the issue was originally opened, but it does show that the problem is no longer present. STL, Gcode, and JPG for reference: http://dl.dropbox.com/u/68192204/bearing5.zip |
I'm attempting to print Emmet's "Gear Bearing", from http://www.thingiverse.com/thing:53451 (A very cool print, if it can be made to work).
The problem I'm having is that the inner (planet) gears are being connected to the outer (ring) gear. This isn't simply an over extrusion issue - the tool path is treating them as though they were the same object.
The attached gcode view illustrates the issue - you can see that the outside perimeter on the inside of the ring gear follows the profile of the planet gears, as though they were connected objects in the STL.
The attached zip contains all of the work in progress - STL, gcode and screen shot.
https://dl.dropbox.com/u/77735649/Bearing5.zip
The text was updated successfully, but these errors were encountered: