kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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.

Thanks Seth.

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
>> segments.
> 
> 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.
> 
> Thanks-
> Seth
> 


-- 
Jean-Pierre CHARRAS