Mail Archives: geda-user/2016/02/09/16:42:35
| 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: | <CAC4O8c-jnHbFzBtWk1YmMfjbt1TeRL9A9tUMUJz_U+18iQfyoA@mail.gmail.com>
|
| References: | <CAJXU7q9H3HZ9dVNvXUt1GuPMimJWaJFTu6wcRKBtPJLU3w0hhA AT mail DOT gmail DOT com>
|
| <CAC4O8c-jnHbFzBtWk1YmMfjbt1TeRL9A9tUMUJz_U+18iQfyoA AT mail DOT gmail DOT com>
|
| Date: | Tue, 9 Feb 2016 21:42:12 +0000
|
| Message-ID: | <CAJXU7q9bedOPLyk0+2kP6rBFaZkdf7QfyD7hxiP_jfJvCYFqtA@mail.gmail.com>
|
| Subject: | [geda-user] Re: Full Polygons
|
| From: | "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
|
| To: | Britton Kerin <britton DOT kerin AT gmail DOT com>,
|
| gEDA User Mailing List <geda-user AT delorie DOT com>
|
| 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
|
--089e011603f6b0a0bd052b5d30f1
Content-Type: text/plain; charset=UTF-8
On 9 Feb 2016 21:19, "Britton Kerin" <britton DOT kerin AT gmail DOT com> 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
<p dir=3D"ltr"><br>
On 9 Feb 2016 21:19, "Britton Kerin" <<a href=3D"mailto:britto=
n DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>> wrote:<br>
></p>
<p dir=3D"ltr">> If connectivity worked, why would we need small fragmen=
t culling?=C2=A0 If<br>
> the fragment unexpectedly shorts something the user can remove it.<br>
> It seems hard to anticipate which fragments are going to be "too<=
br>
> small" so maybe better to let the user decide.</p>
<p dir=3D"ltr">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).</p>
<p dir=3D"ltr">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.<br></p>
<p dir=3D"ltr">> All this somewhat depends on the anticipated use.=C2=A0=
If the point is to<br>
> make layers that fill everything except around lines it seems there=
9;s<br>
> a ways to go and poly might not even be the best way to do that.=C2=A0=
If<br>
> the point is to allow poly in particular places where shielding or<br>
> heat sink is needed then maybe it doesn't matter as much if the us=
er<br>
> has to manually draw and link several polygons, since those are rare<b=
r>
> operations (I've done this a number of times with just rectangles =
and<br>
> lines).</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">> The poly code with it's combination of holes, clear=
line, full poly<br>
> seems really ambitious and I'm vague on exactly what it's tryi=
ng to<br>
> achieve.</p>
<p dir=3D"ltr">The "PolygonType" object is certainly somewhat ove=
rloaded with behaviours :)</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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>
<p dir=3D"ltr">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.<br>=
</p>
<p dir=3D"ltr">> Sounds like there's lot of ongoing work on this fro=
nt so I'm just<br>
> going to add a general caution about eccentric behavior to the full<br=
>
> poly and lines clear polys options and not worry about it any more for=
<br>
> now.</p>
<p dir=3D"ltr">It's fairly slow work, but yes - I'm currently tryin=
g to reach some useful conclusions on the work I started regarding polygons=
.</p>
<p dir=3D"ltr">If you think all the clearance behaviours are ambitious... w=
ait until you see my attempts to add circular arc segment support :)...</p>
<p dir=3D"ltr">It's beautiful when it works, but currently that is the =
rare case, not the usual ;)</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">Peter</p>
--089e011603f6b0a0bd052b5d30f1--
- Raw text -