kicad-developers team mailing list archive

[Evan Shultz <evan.shultz@xxxxxxxxx>]

Here is how another EDA tool handles void control of crosshatched shapes:
[image: image.png]

And the crosshatch fill options, if that is helpful:
[image: image.png]
[image: image.png]

Similarly, I think, shape (zone) suppression is present for non-hatched
shapes because it avoids islands:
[image: image.png]


On Thu, Mar 21, 2019 at 9:41 AM Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> Hey JP,
>
> On 3/21/2019 3:48 AM, jp charras wrote:
> > Le 20/03/2019 à 19:27, Wayne Stambaugh a écrit :
> >> Hi JP,
> >>
> >> Rather than pollute the bug report[1] with feedback about your zone
> >> hatch filling patch, I moved the conversation to the mailing list.  If
> >> anyone else would like to test and comment on this patch, the patch can
> >> be found in the bug report.
> >>
> >> I did some testing and the results look pretty good although it can be a
> >> bit time consuming filling complex zones.  This is to be expected.  One
> >> thing I did notice was that the hatched zone filling appears to leave
> >> really small cutouts in some cases (see attached image).  I know there
> >> is no setting for this but maybe we should use the "Minimum width"
> >> setting to removed excessively small cutouts as well as copper areas.
> >> I'm not sure what users are going to expect here but it's something to
> >> think about.
> >
> > Removing excessively small cutouts is not an easy task for many reasons:
> > - How to recognize a "excessively small cutout"? For an human this is
> > easy. For a computer it is not.
> > - Calculation time will be certainly very expensive.
> > - Most important, our filled areas are polygons with thick outlines.
> > Therefore the polygon itself is small, and its shape is not exactly the
> > filled area shape.
> > Making "excessively small cutout" very hard to detect (the hole area is
> > much bigger than the final hole area)
> > Converting polygons with thick outlines to polygon only creates a lot of
> > vertices.
> > I tried that in Pcbnew a long time ago, and abandoned this idea due to
> > significant calculation time, although it has many advantages.
>
> I wonder how much time it would add to calculate a simple bounding box
> for each cutout polygon and if either bounding box dimension is less
> than the minimum width, remove the cutout.  Have you (or anyone else for
> that matter) looked at how other EDA products handle this?  It might be
> helpful to know in advance so we can make an informed decision.
>
> >
> > As I said previously, grid shaped fill mode can be used only in specific
> > cases, not for "normal" ground planes.
> >
> >>
> >> I also would like you to change the terminology from "grid pattern" to
> >> "hatch" for UI strings, source code naming, and file formatting.  In
> >> other words, the file format token "pattern_thickness" should be
> >> "hatch_thickness", the source code name "m_GridPatternThickness" should
> >> be "m_HatchThickness", and the dialog fill type string type "Grid
> >> Pattern" should be "Hatch". I think "hatch" is more descriptive when
> >> describing this type of zone fill.
> >
> > Yes, but we are already using Hatch option in Outline Display mode in
> > zone settings dialog (and hatch as keyword in .kicad_pcb file).
> >
> > So it can create unclear options in dialog.
> > (and somewhat in file)
>
> I took another look at the file format changes and I noticed another
> issue that I missed.  The new file format tokens are in the "zone"
> settings section.  They should be in the "fill" settings section since
> they are specific to the zone filling.  There is also a extra
> indentation which appears to be incorrect as well.  Here is an example
> of what I'm thinking it should look like:
>
>   (zone (net 0) (net_name "") (layer F.Cu) (tstamp 0) (hatch edge 0.508)
>     (connect_pads (clearance 0.508))
>     (min_thickness 0.254)
>     (fill yes (mode hatch) (arc_segments 32) (thermal_gap 0.508)
>       (thermal_bridge_width 0.508) (hatch_thickness 0.635)
>       (hatch_gap 0.635) (hatch_orientation 0)
>       (hatch_smoothing_level 1) (hatch_smoothing_value 0.25))
>     ) # end fill parameters
>   ...
>   ) #end zone
>
> This puts the hatch parameter under the "fill" section which makes it
> clear that it is a fill parameter rather than a "zone" parameter.
> Reusing tokens is fine as long as they are grouped correctly so that it
> is obvious which group the token belongs to.  In the case above, hatch
> is obviously the type of fill mode.
>
> >
> > Thoughts?
> >
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> [1]: https://bugs.launchpad.net/kicad/+bug/1820493
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>