← Back to team overview

kicad-developers team mailing list archive

  1. kicad-developers team
  2. Mailing list archive
  3. Message #41581

Re: What's the state of the zone outline thickness stuff?

  Thread Previous • Date Previous • • Thread Next 
Hi Jeff-
I just checked a couple of Eagle boards and the imports are now slightly problematic. See the attached image. This corner is square in Eagle. It can be very difficult to edit zones with a bunch of extra points, so I'd like to avoid this if possible. 

Best-
Seth

On 2019-07-15 06:04, Jeff Young wrote:

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

Attachment: RoundedEagleImport.png
Description: PNG image

Follow ups

References

  Thread Previous • Date Previous • • Thread Next