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

offset vs. boolean op inconsistency? #35

Open
mlampert opened this issue Aug 29, 2023 · 2 comments
Open

offset vs. boolean op inconsistency? #35

mlampert opened this issue Aug 29, 2023 · 2 comments

Comments

@mlampert
Copy link

Given below (blue) polylines I create the offsets (green). In order to eliminate interferences the individual offsets are then combined with a boolean OR. The width of the slot in the center line is identical for the C shape and between the 2 squares.

offset

I would've expected the behaviour to be identical for the two cases, either create a segment through the slot or don't. I realize this an edge case, if the offset is slightly larger or smaller the resulting polylines show matching behaviour. Please let me know if my expectation is wrong or if this is an actual issue.

I've build the FFI library from the current master branch.

@jbuckmccready
Copy link
Owner

I think I can explain:

  • The polyline parallel offset function right now always keeps overlapping sections (as seen in the C shape picture).
  • The boolean operations always join closed polylines together when possible (including in the overlapping sections case, as seen in the 2 squares picture).
  • The multi polyline offset function (using the Shape type in cavalier contours right now) doesn't consistently keep or discard overlapping sections (note: this doesn't matter for what you described).

So in the C shape case you performed an offset and ended up with just 1 polyline with an overlapping section, and in the 2 squares case you performed an offset on each square and then the boolean operation joined them together.

It would probably make sense to add an option to the algorithms to control whether to keep or discard overlapping sections and adjust the algorithm code to handle it. Is this option important for your use case?

@mlampert
Copy link
Author

mlampert commented Aug 29, 2023

Great explanation, thanks.

The option on how to deal with "touching" segments would be awesome.

As for context: I'm currently working on a POC to replace the clipper/libarea offsetting in FreeCAD with cavalier contours. To that effect I created a branch which includes (as a copy) the cavalier contours sources and build the FFI library if Rust is installed during the build of FreeCAD (https://github.com/mlampert/FreeCAD/tree/feature/add-cavalier-contours-to-build). This is not my preferred approach but it was the simplest way to get things going and enable other FreeCAD developers to play with cavalier contours.

As a first POC I'm converting the Profile op which basically creates a single offset for a bunch of polylines which then must be combined appropriately to generate valid g-code for the CNC machine.

Eventually consistent behaviour will become important but at this time it's just something I noticed and figured it's worth asking about - CNC operators tend to be rather picky when it comes to machine paths ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants