kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 14/01/2016 01:39, Cirilo Bernardo a écrit :
> On Tue, Jan 12, 2016 at 10:06 AM, Mathias Grimmberger <mgri@xxxxxxxxxxxxx>
> wrote:

<....>

> I'd like to implement arbitrary pad shapes but this requires a functional 2D
> geometry kernel first. I'm starting on one but I may have nothing to
> demonstrate

There is already a geometry kernel in Kicad: Have a look at
include/geometry before writing anything.


> until the end of the year. My plans are:
> 
> 1. develop the geometry kernel + tools to generate PostScript for
> evaluating and
> documenting the kernel
> 
> 2. demonstrate how tracks can be represented as line and arc segments and
> how
> DRC can be performed using the 2D objects.
> 
> 3. demonstrate how pads can be represented by line and arc segments and how
> this relates to DRC.

Pads are already represented by line and arc segments (for ROUND, OBLONG
and ROUNDRECT.

Arc segments can be also accurately approximated by segments: 64
segments give a very good approximation.
But the calculation time when combining too many segments is very long.
This is the price to pay this good approximation.

Free shapes pads are usually defined by polygons.

The main difficulty with complex polygons is to perform a DRC with a
reasonable calculation time.


> 
> 4. demonstrate how a pad can implement filleting (teardrop) or chamfering
> where
> the track/tracks joins the pad.
> 
> 5. demonstrate how fill zones can be represented by line and arc segments,
> how
> DRC can be performed, and how the final zone outline can be calculated. I
> also
> want to demonstrate fill patterns in the zones to implement copper thieving
> and
> also hatched copper fills.

Hatched copper areas need a *fast* algorithm to know if a pad or track
is connected to the area.
This is non trivial.

Filling algorithm itself is very basic,
It exists in Kicad.


> 
> When all that is done and carefully tested then comes the task of adjusting
> kicad to make use of the geometry kernel to represent its pads and tracks,
> and hopefully also zones. If that ever happens it will be an enormous task
> which will affect the plotting, DRC, routing code, and of course the file
> format.
> Personally I think it would be a good thing because we can eliminate these
> horrible piecewise approximations of circular arcs, implement arc tracks,
> and
> implement various other features which are difficult and clumsy to implement
> with the current data models. So - don't hold your breath waiting for
> changes,
> this is far from a trivial task.
> 
> - Cirilo




-- 
Jean-Pierre CHARRAS