Bi-directional offsetting of open paths is already possible (like widening the stroke of a pen). However, uni-directional offsetting is not a likely addition any time soon as it requires an entirely different and similarly complex algorithm that would deserve a separate library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you think that I could edit the result of the Bi-directional offset to get what I look for? I am concerned about open ends closer that offset value.
If you need a sponsor for that, we would like to contribute. Would you add this feature if we pay for it?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd also like to have this feature added asap and am willing to financially support its development and pay for it as a commercial extension. Please let me know if you have any intention to do so.
Thanks,
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Offset of open polygons/paths" means surely "Offset of open paths" because polygons cannot be open. If they are open, they are not polygons.
May be uni-directional offsetting is possible. I'm thinking of first boldening the open path and then converting the original path to polygon A, and use it to clip the boldened path.
The other direction can be achieved by making a "hole" polygon using large enough rectangular polygon which is clipped by polygon A and this resulted polygon is used to clip the boldened path.
A bit complex, but should be possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not quite get it. How would you convert the original path to polygon A? Could you elaborate? Also, even if you can convert a multi-segment path to a polygon, what about a single straigt-line segment path? I think we really need a generic algorithm to handle polyline offset.
Dan
Last edit: Dan Jiang 2014-11-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It was just a first thought for workaround. If the path is very simple, eg. U then it is possible to bolden this using simple butt as endjoin and convert original path to polygon by connecting start and end vertices. This polygon can be used to clip the boldened path, which makes uni-directional offsetting as a result.
But for general algorithm this is not suitable, because joins may differ and open pahts can overlap and they can be straight lines.
Current algorithm calculates unit normal vector (like here: http://ltcconline.net/greenl/courses/202/vectorFunctions/tannor11.gif) to both directions and add points to both. In uni-directional option only one of the unit normal vector end points is chosen. The biggest problem will possibly be which one to choose :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is called there polygon padding and margin. Maybe the code there can give some hints of one possible solution when you Angus have time and interest to think about uni-directional offsetting.
Maybe the code there can give some hints of one possible solution when you Angus have time and interest to think about uni-directional offsetting.
Some years ago I wrote some code for a third party extension to the Graphics32 library (in Delphi) that included unidirectional offsetting. The principles are pretty simple. However, much like the Clipper library, getting the algorithm to work corrected in all circumstances (concave angled joins of short segments, handling self-intersections etc) while also preserving performance is quite tricky.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the GR32_Lines.zip file here look at the Gr32_lines.pas file and in particular the TGrowBase class. It's old code and not particularly elegant.
There's a similar (and more recent) implementation of this path offset algorithm written by Mattias Andersson in the more recent revisions of the Graphics32 library here. Look specifically at the Grow function.
Both these implementations are imperfect solutions, but they both work well most of the time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been thinking about this. It looks like that uni-directional offset of an open path (resulting in another open path) is just a subset of the bi-directional offset of the same path (resulting in a closed path, that is a polygon). In other words, it coincides with a part of the bi-directional offset. So it looks like we just need to find the right start/end points where we need to cut the bi-directional offset and we have what we want.
Do you think there's anything wrong in this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alessandro: In theory, yes, but in practice, it is not that simple. I tried that, but it does not work 100%: too many corner cases to cover resulting in messy, unreliable code.
-Dan
Last edit: Dan Jiang 2014-12-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Angus,
I've already asked in the past, maybe something is changed. Is it possible to offset open polygons/paths?
Thanks,
Alberto
Bi-directional offsetting of open paths is already possible (like widening the stroke of a pen). However, uni-directional offsetting is not a likely addition any time soon as it requires an entirely different and similarly complex algorithm that would deserve a separate library.
Do you think that I could edit the result of the Bi-directional offset to get what I look for? I am concerned about open ends closer that offset value.
If you need a sponsor for that, we would like to contribute. Would you add this feature if we pay for it?
Thanks.
Hi Angus,
I'd also like to have this feature added asap and am willing to financially support its development and pay for it as a commercial extension. Please let me know if you have any intention to do so.
Thanks,
Dan
Not any time soon. Sorry.
"Offset of open polygons/paths" means surely "Offset of open paths" because polygons cannot be open. If they are open, they are not polygons.
May be uni-directional offsetting is possible. I'm thinking of first boldening the open path and then converting the original path to polygon A, and use it to clip the boldened path.
The other direction can be achieved by making a "hole" polygon using large enough rectangular polygon which is clipped by polygon A and this resulted polygon is used to clip the boldened path.
A bit complex, but should be possible.
Hi Timo,
I do not quite get it. How would you convert the original path to polygon A? Could you elaborate? Also, even if you can convert a multi-segment path to a polygon, what about a single straigt-line segment path? I think we really need a generic algorithm to handle polyline offset.
Dan
Last edit: Dan Jiang 2014-11-13
It was just a first thought for workaround. If the path is very simple, eg. U then it is possible to bolden this using simple butt as endjoin and convert original path to polygon by connecting start and end vertices. This polygon can be used to clip the boldened path, which makes uni-directional offsetting as a result.
But for general algorithm this is not suitable, because joins may differ and open pahts can overlap and they can be straight lines.
Current algorithm calculates unit normal vector (like here: http://ltcconline.net/greenl/courses/202/vectorFunctions/tannor11.gif) to both directions and add points to both. In uni-directional option only one of the unit normal vector end points is chosen. The biggest problem will possibly be which one to choose :)
I found one example of uni-directional offsetting of polygons:
http://codepen.io/HansMuller/pen/lDfzt/
It is called there polygon padding and margin. Maybe the code there can give some hints of one possible solution when you Angus have time and interest to think about uni-directional offsetting.
I found the link from github page (https://github.com/w8r/polygon-offset) to which the link I found here:
https://www.npmjs.org/package/polygon-offset
The lib seems nice, but cannot say what it thinks about open path offsetting and different line- and endjoins. I assume that they are not supported.
Some years ago I wrote some code for a third party extension to the Graphics32 library (in Delphi) that included unidirectional offsetting. The principles are pretty simple. However, much like the Clipper library, getting the algorithm to work corrected in all circumstances (concave angled joins of short segments, handling self-intersections etc) while also preserving performance is quite tricky.
Which file contains the implementation of the open path offset code in Graphics32 lib? Maybe I can translate it into C++?
In the GR32_Lines.zip file here look at the Gr32_lines.pas file and in particular the TGrowBase class. It's old code and not particularly elegant.
There's a similar (and more recent) implementation of this path offset algorithm written by Mattias Andersson in the more recent revisions of the Graphics32 library here. Look specifically at the Grow function.
Both these implementations are imperfect solutions, but they both work well most of the time.
I've been thinking about this. It looks like that uni-directional offset of an open path (resulting in another open path) is just a subset of the bi-directional offset of the same path (resulting in a closed path, that is a polygon). In other words, it coincides with a part of the bi-directional offset. So it looks like we just need to find the right start/end points where we need to cut the bi-directional offset and we have what we want.
Do you think there's anything wrong in this?
Alessandro: In theory, yes, but in practice, it is not that simple. I tried that, but it does not work 100%: too many corner cases to cover resulting in messy, unreliable code.
-Dan
Last edit: Dan Jiang 2014-12-17