Hi all,
I did a small investigation of the polygon-related
segfaults/miscalculations. It looks like Boost.polygon badly handles
cases where intersection points of the edges of the polygons lie close
to each other or overlap, causing the 'snap rounding' algorithm used in
boost to go haywire. This i
If I am not mistaken, this is also related to:
https://bugs.launchpad.net/kicad/+bug/1056926
Which referers https://svn.boost.org/trac/boost/ticket/7983
Those two boost bugs could be duplicates?
2015-06-01 18:23 GMT+02:00 Tomasz Wlostowski :
> Hi all,
>
> I did a small investigation of the polyg
Le 01/06/2015 18:23, Tomasz Wlostowski a écrit :
> Hi all,
>
> I did a small investigation of the polygon-related
> segfaults/miscalculations. It looks like Boost.polygon badly handles
> cases where intersection points of the edges of the polygons lie close
> to each other or overlap, causing the
On 6/1/2015 1:09 PM, jp charras wrote:
> Le 01/06/2015 18:23, Tomasz Wlostowski a écrit :
>> Hi all,
>>
>> I did a small investigation of the polygon-related
>> segfaults/miscalculations. It looks like Boost.polygon badly handles
>> cases where intersection points of the edges of the polygons lie c
On 01.06.2015 19:09, jp charras wrote:
> Le 01/06/2015 18:23, Tomasz Wlostowski a écrit :
>> Hi all,
>>
>> I did a small investigation of the polygon-related
>> segfaults/miscalculations. It looks like Boost.polygon badly handles
>> cases where intersection points of the edges of the polygons lie c
Le 01/06/2015 21:32, Wayne Stambaugh a écrit :
> On 6/1/2015 1:09 PM, jp charras wrote:
>> Le 01/06/2015 18:23, Tomasz Wlostowski a écrit :
>>> Hi all,
>>>
>>> I did a small investigation of the polygon-related
>>> segfaults/miscalculations. It looks like Boost.polygon badly handles
>>> cases where
On 01.06.2015 19:09, jp charras wrote:
> Le 01/06/2015 18:23, Tomasz Wlostowski a écrit :
>> Hi all,
>>
>> I did a small investigation of the polygon-related
>> segfaults/miscalculations. It looks like Boost.polygon badly handles
>> cases where intersection points of the edges of the polygons lie c
On 6/2/2015 2:32 PM, Tomasz Wlostowski wrote:
> On 01.06.2015 19:09, jp charras wrote:
>> Le 01/06/2015 18:23, Tomasz Wlostowski a écrit :
>>> Hi all,
>>>
>>> I did a small investigation of the polygon-related
>>> segfaults/miscalculations. It looks like Boost.polygon badly handles
>>> cases where
On 02.06.2015 20:32, Wayne Stambaugh wrote:
>> > I'm almost done with SHAPE_POLY_SET class for the geometry library, a
>> > Clipper wrapper adding some missing Clipper features needed in Kicad
>> > (e.g. polygon fracturing). I'll send a patch soon (affecting only
>> > AddClearanceAreasPolygonsToPol
Hi Tom,
just for reference, you can find a benchmark of various polygon libraries here:
http://rogue-modron.blogspot.de/2011/04/polygon-clipping-wrapper-benchmark.html
It shows as well that Clipper performs better than Boost.Polygon and thus is a
good selection. And CGAL is well known but slow
On 08.06.2015 19:42, "Torsten Hüter" wrote:
> Boost.Geometry (not Boost.Polygon) - because this library has almost the same
> performance compared to Clipper but is more general; because they use
> metaprogrammin
Hi Torsten,
Thanks for the tip. I've known this performance comparison, it shows
C
On 06/01/2015 06:23 PM, Tomasz Wlostowski wrote:
> Hi all,
>
> I did a small investigation of the polygon-related
> segfaults/miscalculations. It looks like Boost.polygon badly handles
> cases where intersection points of the edges of the polygons lie close
> to each other or overlap, causing the
On 6/12/2015 11:25 AM, Maciej Sumiński wrote:
> On 06/01/2015 06:23 PM, Tomasz Wlostowski wrote:
>> Hi all,
>>
>> I did a small investigation of the polygon-related
>> segfaults/miscalculations. It looks like Boost.polygon badly handles
>> cases where intersection points of the edges of the polygon
13 matches
Mail list logo