kicad-developers team mailing list archive
Mailing list archive
Re: What's the state of the zone outline thickness stuff?
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.
> 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.
> 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.
>>> 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 ?
>>> 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
>>> 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).
>>> 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
>>> of jtSquare. I *think* this makes the zero-width-border algorithm
>>> materially indistinguishable from the old algorithm (well, except
>>> 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.