Feature idea: dynamic zone fills and related improvements

I had this thought on how to improve on the odd-even zone fills. Instead of spanning the area, start with the zone shape itself. Subtract all shapes occupying surface on the layer inside it; the remainder is the unoccupied shape, which becomes the shape of the zone itself.

While obviously more computationally demanding, not to mention potentially complex to implement, it has several advantages:

  1. It can be used to fill any subshape of a zone, for example if a footprint is placed its bounding box can be intersected with zones, and the resulting intersections have their fill shapes recalculated, reducing the overhead to only the affected portions. As you draw traces, place footprints, vias, and change board settings zone fill shapes can be dynamically recalculated and redrawn. This would be a benefit as it would allow immediate visual feedback on the impact on fills.
  2. Arcs produce fill shape arcs rather than line steps
  3. The zone edges are no longer immutable and can respect clearances (for an odd-even fill to do this it would need to go all the way back to the board edges)
  4. Zones become geometric shapes and can be placed on any layer including silk, so you could have a silk rectangle with clearance for vias if you wish
  5. Zones can be filled with any pattern (e.g. a thieving pattern)
  6. Zones can be placed anywhere in the priority order

Hybrid optimizations might be possible, for example: find a known unoccupied point within a bounding box and odd-even fill to the borders of the bounding box, but this obviously won’t produce a mathematically correct fill shape and the tradeoff between fill segment width and gerber size/complexity remains. (It also needs to be repeated until there are no more unfilled islands.)

This “Feature Request Chat” section is targeted more for features which average end users can understand because the forum is for users by users. I’m programmer by education (and even by occupation every now and then) and I follow KiCad development, but I don’t understand what you are saying. Not all developers follow these discussions. You probably should take the conversation directly to the developers mailing list or file it as a bug report (wishlist item).

Also: one bug report per feature request. Oh and feature requests should lay out a usecase not be a suggestion for a solution (the reporter most likely has not all information available to know how to support a usecase and if devs are left guessing at the usecase then it is very unlikely to be considered)

1 Like

Ah well, if it doesn’t belong here just delete the topic. I don’t have permission to do so.

There’s no need to delete this. It just doesn’t reach the target audience or get useful response here.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.