You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, let me mention that I'm not familiar with computational geometry. My background is in optimization. In particular, I develop an open-source library for geometrical packing problems. I would like to add to this library a module to solve problems of packing arbitrary polygons. Hence my need for computational geometry tool.
To pack arbitrary polygons, there are several known strategies in the literature. Most of them rely on a routine able to find valid positions for a polygon inside the container where the positions of some other polygons have already been fixed.
One implementation of this routine uses the no-fit polygon. The no-fit polygon between polygon A and polygon B is the polygon such that if polygon A is placed strictly inside, it intersects polygon B. To find valid positions for polygon A, we compute the union of its no-fit polygon with all other already packed polygons and the container. Then we choose one point on the exterior of the no-fit polygon to pack polygon A.
From what I've understood, the no-fit polygon is strongly related to the Minkowski difference. In the example from Clipper2 documentation http://www.angusj.com/clipper2/Docs/Units/Clipper/Functions/MinkowskiDiff.htm we see that the no-fit polygon of the circle corresponds to the outer part of the path. The issue for me here, seems to be that Clipper2 computes the Minkowski difference between paths, and not between polygons. So, the output contains some irrelevant positions for packing. Would there be a way to get the Minkowski difference between two polygons (potentially with holes)?
Another implementation of the routine to find a valid position is to fix the x-coordinate of the polygon to pack, and find a valid y-coordinate. This requires a routine that doesn't compute the intersection between two polygons, but returns "how much should the first polygon be translated up so that it doesn't intersect the second polygon anymore?" I don't know if that fits in Clipper2's scope, but that's something that would be useful to me.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi,
First, let me mention that I'm not familiar with computational geometry. My background is in optimization. In particular, I develop an open-source library for geometrical packing problems. I would like to add to this library a module to solve problems of packing arbitrary polygons. Hence my need for computational geometry tool.
To pack arbitrary polygons, there are several known strategies in the literature. Most of them rely on a routine able to find valid positions for a polygon inside the container where the positions of some other polygons have already been fixed.
One implementation of this routine uses the no-fit polygon. The no-fit polygon between polygon A and polygon B is the polygon such that if polygon A is placed strictly inside, it intersects polygon B. To find valid positions for polygon A, we compute the union of its no-fit polygon with all other already packed polygons and the container. Then we choose one point on the exterior of the no-fit polygon to pack polygon A.
From what I've understood, the no-fit polygon is strongly related to the Minkowski difference. In the example from Clipper2 documentation http://www.angusj.com/clipper2/Docs/Units/Clipper/Functions/MinkowskiDiff.htm we see that the no-fit polygon of the circle corresponds to the outer part of the path. The issue for me here, seems to be that Clipper2 computes the Minkowski difference between paths, and not between polygons. So, the output contains some irrelevant positions for packing. Would there be a way to get the Minkowski difference between two polygons (potentially with holes)?
Another implementation of the routine to find a valid position is to fix the x-coordinate of the polygon to pack, and find a valid y-coordinate. This requires a routine that doesn't compute the intersection between two polygons, but returns "how much should the first polygon be translated up so that it doesn't intersect the second polygon anymore?" I don't know if that fits in Clipper2's scope, but that's something that would be useful to me.
Beta Was this translation helpful? Give feedback.
All reactions