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=BFZHEI8uAjZJGH1dnu7KFC+a1PSH2KdwSvcgfuHPIfs=; b=XeK4RHr4mn4uiGY/goOmXihYFsZ4XT8FCiXTIBmEG9NVmfDv4k8ed/0sOsLL9qcD1l Slk4aQT/1f7LVaGyBogH3VCZWSxmbn7u+/q3gxXRHC1Lu6kfIJjiYfeZB046H0yN60gd 9inm0VG7IxY7YV2H/RoVQbZlDYzzAFVNwMcVMyLZfhM5iSDccjsb7VcP7GqBAgAPUiro MAWrwHYQ96YgYo2mpLk3E2pJ8e6dFvMFW5AjswAng4PQjm+T/KoHQwP7PNtFNqedPJE2 UbQHckgxLkR3MA5gWwR3+/T7EIArPy46QhqQpfGx4BobnV7GB5DzKKVUTd5uIeRvU3oW Rtxw== MIME-Version: 1.0 X-Received: by 10.202.85.146 with SMTP id j140mr6795300oib.4.1450814076074; Tue, 22 Dec 2015 11:54:36 -0800 (PST) In-Reply-To: <20151222184519.GO14853@abax> References: <20151222144719 DOT GN14853 AT abax> <20151222184519 DOT GO14853 AT abax> Date: Tue, 22 Dec 2015 19:54:36 +0000 Message-ID: Subject: Re: [geda-user] Self-intersecting polygon appears because of intersection coordinates rounding From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List Content-Type: text/plain; charset=UTF-8 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 Did you spot that there was some incorrect vertices being generated for certain cutouts? (polygon.c)? I think my branch fixed some of those.. The way to tell is dial down the number of vertices being used to approximate a circle.. (can't recall, but possibly polygon.h?) You will see that things get quite badly distorted if the bug is present. Changing to (say) 4-8 segments should make it very clear if the bug is still there. So - we have: 1. Some bad geometry in the circular approximations. 2. Sometimes we get rounding errors, that make polygon edges which should end up as exactly straight, out by 1 or 2 nm over their length - which produces tiny little polygon slivers that are prone to problems, and rounding. 3. Polygon routines that can (under certain circumstances - I forget _all_ the details) - walk along the wrong contour, and produce completely incorrect results. I'd be curious to see you assessment as to whether your recent fix in git HEAD is similar, different, or addresses a similar bug to those addressed in my branch. Many apologies to everyone for sitting on these for so long... I'd guess there was a reason (such as that I wasn't 100% confident in my fix - looks like there was still a few "hmm... ?" type comments left in there. Martin - I can't promise a lot of availability, but would you be up for some shared effort on this (perhaps chat on IRC at some point?) to try to dig to the bottom of these issues once and for all? I doubt we'll solve snap-rounding (with any elegant algorithm - unless we do a mad re-write), but according to Harry Eaton's old comments- It appears he thought the iterative intersection + edge splitting approach taken within PCB ought to have avoided the problem. Peter Peter On 22 December 2015 at 18:45, Martin Beranek wrote: > Hi Peter, > >> I'd be interested to know how you got on running your board against >> this old branch of mine: >> >> http://www.repo.or.cz/geda-pcb/pcjc2.git/shortlog/refs/heads/for_master2 > > OK, tested now. Compiling from this branch directly, I do not have this > problem on my test board, but there is a lot of changes including > size/shape of the clearout around lines/pads as it looks like (I did not > analyzed things in details yet, but it seems that coordinates of > polygon vertices are slightly different). > > So I decided to take polygon1.c only and transplant it into the main pcb > branch. Now, it seems that the buggy intersection calculation happens, > but without any adverse effect on polygon rendering. It seems that order > of collecting is different because of other changes and the collect does > not run over problematic edges. > > But with small modification (letting ground fill into one previously > clear area), I was able to make polygon disappear after component move > in almost the same way as in the main branch. > > I do not have enough debug info processed yet, so it is maybe another > vertex/edge causing the bug this time. > > > While I was not able to reproduce the issue with the clean pcb version from > your branch, I believe it is not fixed there, it would just occur for > some different layout as lot of things related to polygons is changed > and I am not getting the 'right' vortices (coordinates) there with my > test board. > > > > Martin >