-
Notifications
You must be signed in to change notification settings - Fork 4
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
[BUG] Pocket clipper does not generate correct paths for circles #60
Comments
Possible to provide the code for a MRE? And slightly elaborate the issue? Is it the excessive retracts? |
From what I understood this is an issue with pyclipper. It seem to be working by discretizing paths into points and then offsetting those points. Hence if the precision of the discetization is too low, arcs and splines are a very low resolution approximation of the real thing. If you increase the precision then pyclipper generates hundreds of tiny line segment and a result hundreds of G1 commands taking tiny steps. |
Correct, clipper works only with linear segments. See #11 for notes on exploring using OCCT for offsetting. Unfortunately it's a very buggy road. Short summary out of my memory: Clipper pros
Clipper cons
OCCT pros
OCCT cons
Currently the clipper pocketing is the default one because it's far more reliable, but I'm certainly open for attempting to put more effort on the OCCT pocketing. Profiling still uses OCCT offsetting (generally it's a bit harder to hit these edge cases in the offsets used for profiling) |
Precision issues in arc/circle interpolation can also be related to my recent changes in #44 Clippers ArcTolerance was a bit tricky to tie into precision and I may have made poor choices there. |
From my experiments clipper is much slower (if you increase the precision to get smooth paths) There is a library in rust called kurbo that recently implemented robust offset curves. The library itself contains all the primitives you can find in OCCT but the offset logic was for splines. I will ask around in their forum to check if it can be generalized and if it is I can start creating bindings for python |
My problem with the offsetting provided by cadquery and subsequently OCCT is that it is not translation and rotation invariant. So if you were to translate or rotate a design before using the offset it would appear in the wrong place. My solution is a bit convoluted and I am not sure that it is the most efficient way to do thing but it has been robust so far (apart from when working with cq_cam for some reason; then I have to reverse to the old offset2D code). Here is my code:
|
I scanned through OCCT bugs and roadmap and it seem like they are going to address some offsetting bugs for OCCT 7.8! |
That's interesting, I need to check that particular bug out. I'm also delighted to see that you've already taken a deep dive into this topic on the OCCT side. Should we try implementing a centralized |
I just spent the entire morning investigating why my offset bug fix does not work on cq_cam and I think I have an explanation. It might require me to dig in deeper. So the bug is a bit more comlex than I originally thought so I will be posting a more detailed discussion later on with code samples. |
I will also need to open separate issues for the offsetting bug to keep the discussion relevant. On another note, I have talked to the kurbo guys and they are keen on supporting our usecase. Their code does indeed work with beziers for which they provide curve fitting algorithms to convert arbitrary curves to beziers. The you can execute the offsetting code and you get beziers (quadratic) as an output which you can then flatten and generate G0/G1 commands. I also asked if there is a way to convert bezier back into arcs to support G2/G3 commands and while they don't support this usecase just yet they are happy to add it. I think I will investigate this further locally and then try to integrate it into cq_cam |
That's not that bad of an idea! |
kurbo is definitely pretty interesting, very interested to see how that will evolve. How did you find out about it?
Uh, impossible to say just from the picture what's going on there, but that sure does look pretty amusing. The circle offset bug in OCCT that I've made the workaround against should result in an offset that is on a different plane in the direction of the face normal, so most likely this is something completely else. Is it clipper or OCCT offset? In any case that feels/looks like a bug in our code rather. |
Ref to the separate issue you created on offsetting: #61 |
The text was updated successfully, but these errors were encountered: