kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Hi Tom,

Thanks for the detailed feedback. I was definitely thinking of this as a
long-term (post 5.0) project.  I will take a look at the various aspects
you mention and come back with a more detailed proposal.

Regarding DRC, are you the person in the best place to start that
specification/discussion when the time is right?  I will leave DRC out of
my zone filling exploration for now, but I think there might be some common
underlying technology at some point.

For my demo I just refill after the PNS route is committed.  I wanted to do
it live but saw that it would be way more complicated since the data is not
yet committed to the board.  For a real implementation we would have to
look at better ways of doing this.

Thanks,
Jon

On Tue, Sep 19, 2017 at 12:24 PM, Tomasz Wlostowski <
tomasz.wlostowski@xxxxxxx> wrote:

> On 19.09.2017 15:26, Jon Evans wrote:
> > Yes, I used Xpedition in a past life and one of my missions is to bring
> > some of its cool features to KiCad :-)
> >
> > JP, I will do some tests on more complex boards and look in to possible
> > solutions.
> > I think this is quite a big challenge but want to take it on, because I
> > think some of the underlying work needed will also be very useful for
> > other things (like live DRC checking, autorouting, etc)
> >
>
> Hi Jon,
>
> Nice idea. I'm not sure the main bottleneck is the actual polygon
> processing. Zone filling takes several steps:
> - preparing the geometry (clearance areas of items within the zone) -
> AddClearanceAreasPolygonsToPolysList_NG
> - polygon clipping (SHAPE_POLY_SET::BooleanXXX)
> - removing insulated copper islands
> (CONNECTIVTY::FindInsulatedCopperIslands)
>
> All of these are quite computationally expensive, but as you mentioned
> the zones can be partitioned to refill only the affected parts. Even
> without any partitioning, drawing a trace usually affects 1-2 zones on
> the current layer. Maybe updating only the zones that collide with the
> currently routed trace would be fast enough?
>
> There are also some other things to take into account:
> - there is a form of zone partitioning (see class POLY_GRID_PARTITION),
> which splits a zone into a grid of rectangles for fast point-in-polygon
> check. Maybe something similar could work for in your case.
>
> - the BOARD model is not thread-safe - that's why the
> ratsnest/connectivity is not updated in a separate thread yet, even
> though we have new connectivity algorithm. I would advise first cleaning
> up the BOARD storage and way it can be accessed before embarking on any
> multithreading. This is something we'd like to do after releasing the
> V5. For the moment, Orson's idea with the timer looks safest.
>
> - PNS uses its own private data model for the moment, which is synced up
> with the BOARD after drawing/editing a trace. I did it this way to have
> fast spatial indexing, something that live zone filling could also
> benefit from. How do you update the BOARD data (so that the zones could
> be refilled) while the track is being routed in the patched version you
> showed in the video?
>
> - We need to discuss DRC (including on-line DRC) in detail before we
> start implementing any serious changes. There has been a lot of requests
> on the mailing list/forums and this is IMHO complex enough to deserve a
> specification.
>
> Cheers,
> Tom
>