kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

Oh, good.  Not sure how I missed where we set the min-width.

So our old algorithm will mimic Eagle irregardless of my change (MiterLimit only comes into play when inflating, not when deflating).

However, the new algorithm would need my change to produce the same curves as Eagle — but that puts us nearly back to square one vis a vis the performance issues JP was addressing.

So, live with squared-off Eagle corners when the angles are above 90º?

(I also though about setting a smooth-sharp-corners option in the Eagle importer, but Eagle imports are more likely to be complicated boards which run into performance issues.)

Cheers,
Jeff


> On 15 Jul 2019, at 01:24, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
> 
> Hi Jeff-
> 
> Right now we do (a) except that we set the min-width to 1/2 the Eagle stroke width [1].  This is because we stroke inside the zone outline.  Eagle rounds using the edge of their line, which is curved to 1/2 the width.
> 
> Best-
> Seth
> 
> [1] https://git.launchpad.net/kicad/commit/?id=490c805319974ec84a8fbe8b10e9b59b9a3922a6
> 
> On 2019-07-14 16:13, Jeff Young wrote:
>> Hi Seth,
>> I’m still not following this.  When Eagle strokes the boundary, it
>> does so with a round pen (at least going by the pngs in the bug
>> report).  So all corners have a radius of 1/2 the stroke width.
>> How do we currently represent that in Kicad?
>> a) inflate the boundary by 1/2-eagle-stroke-width and set min-width to
>> eagle-stroke-width?
>> b) inflate the boundary by 1/2-eagle-stroke-width and set corner
>> filleting to 1/2-eagle-stroke-width?
>> c) inflate the boundary by 1/2-eagle-stroke-width and let Clipper
>> round the corners?
>> If it’s (c), I’m saying that doesn’t actually work. (Or at least it
>> didn’t.)  You’re probably seeing the effects of (a), only with a
>> default min-width so the radiuses won’t necessarily exactly match.
>> I’ve changed (c) to also round by 1/2-min-width, so that it can be
>> equivalent to (a) when “stroke-zone-boundaries” is off.
>> Cheers,
>> Jeff.
>>> On 14 Jul 2019, at 20:21, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
>>> Hi Jeff-
>>> The bug was that Eagle strokes on the boundary.  We stroke inside.  When we convert, we need to expand strictly as a square to get the equivalent KiCad zone.  Mitering and rounding will give excess polygon points.  The only way I have found to get this in Clipper is to use jtMiter and set the miterlimit to 0.  Oddly, just setting the parameter to jtSquare gave a mitered corner.
>>> It sounds from your description that you've changed this behavior in Clipper.  If that is the case, Eagle converted zones will no longer be correct.
>>> -Seth
>>> On 2019-07-14 14:22, Jeff Young wrote:
>>>> Hi Seth,
>>>> I looked at that bug report, and all the Eagle zones have rounded
>>>> corners, not square.  So I don’t think you were actually getting
>>>> anything out of the mitering, but that was being masked by the fact
>>>> that we _do_ in fact stroke the outer zone boundary (therefore giving
>>>> you rounded corners).
>>>> Just to be clear, we stroke with the zone-min-width stroke, rather
>>>> than the zone boundary’s linewidth.  We first deflate the zone by
>>>> 1/2-min-width (which drops out all the min-width features), and then
>>>> stroke it with min-width which expands it back to size and gives us
>>>> some corner rounding as a bonus.
>>>> JP has recently introduced a new mode where we don’t stroke the
>>>> boundary anymore (I think primarily for performance, but I’m not
>>>> 100% sure).  Under this algorithm we still deflate the zones by
>>>> 1/2-min-width, but we then inflate them again to bring them back to
>>>> size.  My changes are largely to add corner rounding to this case.
>>>> Cheers,
>>>> Jeff.
>>>>> On 14 Jul 2019, at 18:53, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
>>>>> Please be super careful here.  I was using that implicit fallback in
>>>>> the Eagle import to get a square inflation that is needed to mimic
>>>>> the Eagle zones.  I didn't think we were using that type of
>>>>> inflation anywhere else (but that could have changed).  If we are
>>>>> using that elsewhere, can you verify that the change to clipper
>>>>> doesn't re-introduce https://bugs.launchpad.net/kicad/+bug/1817312 ?
>>>>> Thanks-
>>>>> Seth
>>>>> On 2019-07-14 13:17, Jeff Young wrote:
>>>>> Hi Seth,
>>>>> We weren’t calling it directly anywhere.  But jtMiter has a
>>>>> MiterLimit, after which it falls back to square.  I’ve changed
>>>>> that
>>>>> fallback to round (and enforced a much lower MiterLimit so that it
>>>>> mimics the smoothing we used to get by drawing the border with a
>>>>> 1/2-min-width thick stroke).
>>>>> Cheers,
>>>>> Jeff.
>>>>> On 14 Jul 2019, at 17:50, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
>>>>> On 2019-07-14 05:31, Jeff Young wrote:
>>>>> I made another optimisation, this time within the Clipper library.
>>>>> When the offset exceeds the MiterLimit it will perform jtRound
>>>>> instead
>>>>> of jtSquare.  I *think* this makes the zero-width-border algorithm
>>>>> materially indistinguishable from the old algorithm (well, except
>>>>> that
>>>>> several bugs are fixed in the new one and it’s faster).
>>>>> Hi Jeff-
>>>>> Were we using jtSquare somewhere?  I had added an option to inflate
>>>>> using jtMiter but this was for Eagle import only.  I thought all
>>>>> other inflations were using jtRound.
>>>>> Best-
>>>>> Seth