X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5PkrU+LKzdvtv3Wedx382LxxTmjhuUdpr5Md3/4xvV0=; b=Vbl8N+2A4ZkCekuo5YY8ieraCvfKf3sjJ2vW2UNTisC3IjrsJby2c0DRXLk8rcIxzK aYxMWXgY/rWecsKF9INFCbaozVBoXe6sbn2gDO3+vF3dRRGtUvyl7PKUEPg8rZKLtP9/ Yz3teTPkaT8nXqc8j3yFgm8WCb1Q1I+Nb/+O7FoDkzFrPBxZ8jtrza+fzZCVmyGva3Bm 1lEWEwrBjTlYfMvM18j9IVoXhpm2E7v6uB9y9gV3qzzRyJRpOEs3JZkv4quNJEBfO0M+ ZyY4/3TTvL44ie4e7rFcQJveAiw0mU01qSNhBcA01q5etCNe5cXS2oHxH1r7vEkX8y48 mKhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5PkrU+LKzdvtv3Wedx382LxxTmjhuUdpr5Md3/4xvV0=; b=HzZupCSR0bi7ugjHL6Yjs0pqvkOnzv2zzG1H1do/pH6/fXR77XJIOJisG4JLBceypi D27QbopfW/EQzJUBVod5tt+z1ImWbWrUlcchExw1gBG3j0JewQGeWmpDLNg2WcjWDZON Ml26oxRUg3CaG0ARmBG5eOQtzfHd9MHthW+VMf7j6qzQCrYqPI0XhNbym0ieQ/tD2AZC USGAq7BTl9OklEPZxXj1F3MrDT+9/9wQy7Ou4D/XbJ6wdzg4w2O1fJaoIdvV5nMhqGXG TKw9GAdrWAtubYl/YBkLzB8OSUP4Nw7WE8H5Rr5CBcKeJvMPZphBp1NLrNluiq3GYzIC QkgA== X-Gm-Message-State: AG10YOQUu0fXVrVxD1SZhijD1rKZiiC94rUyZD8ktWOFd1hdqZXcAe2wXTWab2rx6+/kQLozJO5mSWCNBYVsTQ== MIME-Version: 1.0 X-Received: by 10.60.94.82 with SMTP id da18mr31623997oeb.40.1455054132385; Tue, 09 Feb 2016 13:42:12 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Feb 2016 21:42:12 +0000 Message-ID: Subject: [geda-user] Re: Full Polygons From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" To: Britton Kerin , gEDA User Mailing List Content-Type: multipart/alternative; boundary=089e011603f6b0a0bd052b5d30f1 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --089e011603f6b0a0bd052b5d30f1 Content-Type: text/plain; charset=UTF-8 On 9 Feb 2016 21:19, "Britton Kerin" wrote: > > If connectivity worked, why would we need small fragment culling? If > the fragment unexpectedly shorts something the user can remove it. > It seems hard to anticipate which fragments are going to be "too > small" so maybe better to let the user decide. Indeed, the option is present in git HEAD, and can be saved in the pcb file. It is old code from around the time Harry implemented the polygon algebra, but it has been long disabled. When I tired to enable it, I discovered why.... in the way it was implemented, it broke the incremental polygon calcs., as they need to be able to reconstruct a local area incrementally (which needs all the shards). The problem with shards has never been connectivity... it is manufacturing related, as small undersize fragments like you often get a lot of with full polys, may violate the manufacturing design rules. What happens if there is not enough area, is that the shards of copper delaminate from the FR4 and can cause sorts on the board. > All this somewhat depends on the anticipated use. If the point is to > make layers that fill everything except around lines it seems there's > a ways to go and poly might not even be the best way to do that. If > the point is to allow poly in particular places where shielding or > heat sink is needed then maybe it doesn't matter as much if the user > has to manually draw and link several polygons, since those are rare > operations (I've done this a number of times with just rectangles and > lines). The "lots of linking polygons" approach we currently need as a workaround is not ideal, as combined with the "biggest piece keeping" can require a tangled mess of drawn polygon shapes to successfully fill an area bordered by tracks. > The poly code with it's combination of holes, clearline, full poly > seems really ambitious and I'm vague on exactly what it's trying to > achieve. The "PolygonType" object is certainly somewhat overloaded with behaviours :) For the pours stuff, I think I ended up introducing a new "PourType" which represented the user drawn area, and held the behaviour flags... (confusingly this then got tied to the "Polygon []" aspect of the file format, for compatability reasons. The PourType object would then automatically spawn separate PolygonType children for each isolated body of the boolean result from clipping the user input shape with any required clearances from other objects. Doing it this way only required minimal changes to the connectivity scanning code, although at one point I also tried it with "PolygonType" and "PolygonPieceType", which had a bigger editing delta, but matched closer with existing names used in the file format. > Sounds like there's lot of ongoing work on this front so I'm just > going to add a general caution about eccentric behavior to the full > poly and lines clear polys options and not worry about it any more for > now. It's fairly slow work, but yes - I'm currently trying to reach some useful conclusions on the work I started regarding polygons. If you think all the clearance behaviours are ambitious... wait until you see my attempts to add circular arc segment support :)... It's beautiful when it works, but currently that is the rare case, not the usual ;) Turns out nanometers are quite fiddly small units... I may need to apply a bit of coarser rounding to the intersection results, and hopefully fix up the topology to match. I spent this morning and most of my train journey so far writing a tree view gui to visualise the sequence of polygon boolean operations which combine to form a resulting clipped contour. By interactively selecting one of the intermediate results I can now start to more easily check where and why a particular case falls over. (In my current one, I have suspicions of the vertex bunch sitting about 1-2 nm apart from each other, as a likely place the geometry / topology calcs may be getting upset. Peter --089e011603f6b0a0bd052b5d30f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 9 Feb 2016 21:19, "Britton Kerin" <britton DOT kerin AT gmail DOT com> wrote:
>

> If connectivity worked, why would we need small fragmen= t culling?=C2=A0 If
> the fragment unexpectedly shorts something the user can remove it.
> It seems hard to anticipate which fragments are going to be "too<= br> > small" so maybe better to let the user decide.

Indeed, the option is present in git HEAD, and can be saved = in the pcb file. It is old code from around the time Harry implemented the = polygon algebra, but it has been long disabled. When I tired to enable it, = I discovered why.... in the way it was implemented, it broke the incrementa= l polygon calcs., as they need to be able to reconstruct a local area incre= mentally (which needs all the shards).

The problem with shards has never been connectivity... it is= manufacturing related, as small undersize fragments like you often get a l= ot of with full polys, may violate the manufacturing design rules. What hap= pens if there is not enough area, is that the shards of copper delaminate f= rom the FR4 and can cause sorts on the board.

> All this somewhat depends on the anticipated use.=C2=A0= If the point is to
> make layers that fill everything except around lines it seems there= 9;s
> a ways to go and poly might not even be the best way to do that.=C2=A0= If
> the point is to allow poly in particular places where shielding or
> heat sink is needed then maybe it doesn't matter as much if the us= er
> has to manually draw and link several polygons, since those are rare > operations (I've done this a number of times with just rectangles = and
> lines).

The "lots of linking polygons" approach we current= ly need as a workaround is not ideal, as combined with the "biggest pi= ece keeping" can require a tangled mess of drawn polygon shapes to suc= cessfully fill an area bordered by tracks.

> The poly code with it's combination of holes, clear= line, full poly
> seems really ambitious and I'm vague on exactly what it's tryi= ng to
> achieve.

The "PolygonType" object is certainly somewhat ove= rloaded with behaviours :)

For the pours stuff, I think I ended up introducing a new &q= uot;PourType" which represented the user drawn area, and held the beha= viour flags... (confusingly this then got tied to the "Polygon []"= ; aspect of the file format, for compatability reasons.

The PourType object would then automatically spawn separate = PolygonType children for each isolated body of the boolean result from clip= ping the user input shape with any required clearances from other objects.<= /p>

Doing it this way only required minimal changes to the conne= ctivity scanning code, although at one point I also tried it with "Pol= ygonType" and "PolygonPieceType", which had a bigger editing= delta, but matched closer with existing names used in the file format.
=

> Sounds like there's lot of ongoing work on this fro= nt so I'm just
> going to add a general caution about eccentric behavior to the full > poly and lines clear polys options and not worry about it any more for=
> now.

It's fairly slow work, but yes - I'm currently tryin= g to reach some useful conclusions on the work I started regarding polygons= .

If you think all the clearance behaviours are ambitious... w= ait until you see my attempts to add circular arc segment support :)...

It's beautiful when it works, but currently that is the = rare case, not the usual ;)

Turns out nanometers are quite fiddly small units... I may n= eed to apply a bit of coarser rounding to the intersection results, and hop= efully fix up the topology to match.

I spent this morning and most of my train journey so far wri= ting a tree view gui to visualise the sequence of polygon boolean operation= s which combine to form a resulting clipped contour.

By interactively selecting one of the intermediate results I= can now start to more easily check where and why a particular case falls o= ver. (In my current one, I have suspicions of the vertex bunch sitting abou= t 1-2 nm apart from each other, as a likely place the geometry / topology c= alcs may be getting upset.

Peter

--089e011603f6b0a0bd052b5d30f1--