kicad-developers team mailing list archive
Mailing list archive
Re: PCBNew: Segments/polygons not rendered correctly (from Bug 1806411])
Le 17/12/2018 à 22:26, Seth Hillbrand a écrit :
> Hi JP-
> Am 2018-12-17 08:47, schrieb jp charras:
>> Note the incorrect rendering happens only when footprints are flipped.
> Thank you for the samples. I had coded the tesselation assuming the
> copper layers, which always have the polygon in CW order for the outline
> and CCW for the holes. But flipped footprints put the line chain in the
> reverse order, so they render incorrectly.
> I've added some checks for the winding order to the code and re-enabled
> the polygon caching. Let me know if you see any issues.
Could you have a look into my commit 388397f97.
I want to be sure I did not break your code.
I modified Gerbview to use your tesselation.
During my tests, I found a crash with degenerated polygons (having less
than 3 corners).
(the gerber test file test_polygons_with_arcs.gbr has degenerated polygons)
So I added code to skip degenerated polygons in tesselation.
>> I am not familiar with the PolygonTriangulation:: code
>> and, of course, I can be wrong,
>> but I am worried by this code in
>> PolygonTriangulation::TesselatePolygon( const SHAPE_LINE_CHAIN& aPoly )
>> if the first attempt to tesselate aPoly does not work, a second attempt
>> is made on a "simplified" polygon, using this code:
>> ClipperLib::Paths simplified;
>> ClipperLib::SimplifyPolygon( aPoly.convertToClipper( true ),
>> simplified );
>> If aPoly is self intersecting it can work, but our polygons are usually
>> not intersecting, but are polygons with holes linked by overlapping
> The second step should never be called on normal polygons. It exists
> there to solve a specific error created by a third-party footprint
> generator where they had two, overlapping line chains of the same size,
> in different order. Normally, we wouldn't add code to handle someone
> else's error but since it used to work with the OpenGL tesselation and I
> couldn't _guarantee_ that pcbnew couldn't generate a similar polygon, I
> added the second step.
> You are correct that the simplify code could produce polygon sets with
> holes. I've corrected this behavior to return the failure up to
> shape_poly_set for fracturing before trying again.