Replies: 1 comment 1 reply
-
Replace: Clipper2/CPP/Clipper2Lib/src/clipper.offset.cpp Lines 23 to 29 in 0a6a3ab Clipper2/CPP/Clipper2Lib/src/clipper.offset.cpp Lines 514 to 518 in 0a6a3ab with
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am mainly interested in offsetting.
In various areas people have to work with input that is currently not supported by Clipper: 0-area closed polygons.
For example one of our applications is calculation of 2d shadow based on triangle mesh. To imagine what this is - just project every triangle on XY plane and do boolean OR of 3-point closed polygons defining each triangle. The result will be a "shadow" of the input mesh. This shadow can later be used as a 2d map of obstacles for path planning (Maybe there are other usecases for this as well).
The main issue is with triangles that are "standing on the edge" and don't have any width in XY projection. We cannot skip them (as clipper does) because they are still there in the real mesh, and they are still obstacles which should be omitted.
Of course with only 3-point polyline defining each triangle it is relatively easy to turn these closed 0-area polygons into open polys so that clipper can work on them and properly do an offset.
In fact my explanation of mesh shadow algorithm is a bit simplified, and the real implementation works on polygons that have much more than 3 points, any such polyline defines closed edge of a group of adjacent triangles (triangles are grouped together to do less 2d boolean OR calls), and all triangles in this group can be standing on their edge and have 0 area in XY projection, and therefore it is impossible to easily "open" complex polygon like this. I believe there can be a lot of similar usecases where we need to be able to work with 0-area polygons as you do with unclosed paths, but without actually "opening" them, because it is not easy to open arbitrary polygon without area.
What do you think, is it possible to support such input? As I understand the main problem is to understand where is "left" and where is "right" when polygon doesn't have area.
Beta Was this translation helpful? Give feedback.
All reactions