kicad-developers team mailing list archive
Mailing list archive
Re: Zone hatch filling patch
Here is how another EDA tool handles void control of crosshatched shapes:
And the crosshatch fill options, if that is helpful:
Similarly, I think, shape (zone) suppression is present for non-hatched
shapes because it avoids islands:
On Thu, Mar 21, 2019 at 9:41 AM Wayne Stambaugh <stambaughw@xxxxxxxxx>
> 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 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
> >> : 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