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=7IQiVyR/8JzMEASX3+QK0t2bekA1vpMTsCc5QFRRWvk=; b=REkU6bG7NS/s2rW5VyPwQ1J81vA6Wqw3Hpio43zCqfQvKHaKKv8VFQVMz+5tHxnQQZ wUrYdKMsW8jV3nngqqTcjRtYncBFhzKap5OUDYokeoswZY+QUBbV1naCZmbyHTkLcbgf j3PvD/dqb+0O31BKYbNsX9nfzMy1kUnmqWSYuFkf5QZ5AtP/R5uppKk7ihP86L1yya/a h7DWMGA2iKN/+f7VLCpaOPEjgobXmecj8vGWqWZ/q2jiVhyFxV7F1QURDfYypLESYoUV dIqP7hdsvttQKtGjY3KtYll7EtYNZLxYARdSsadTqmYBpr/tE7o20SJvDZvAv6XC1Hmw LkfA== MIME-Version: 1.0 X-Received: by 10.60.232.231 with SMTP id tr7mr1150862oec.27.1450818282539; Tue, 22 Dec 2015 13:04:42 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 21:04:42 +0000 Message-ID: Subject: Re: [geda-user] Project leadership 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 On 22 December 2015 at 20:01, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > > >>> FWIW, My "branch" with the later OpenGl stuff, and 3D support is way >>> more like a fork now, than I'd ever intended it to become. The >>> intention is to merge it, but the blocking problems regarding >>> data-structure and file-format additions have still not been resolved, >>> and my free time has (in complete generality) been reduced a lot. > > What problems are these exactly? I have honest plans to work on the file > format, first simply by separating the parser from the innards of pcb (there > will be a new data structure that corresponds one-to-one with file format). > If there are modest incremental changes that would be useful I'm interested > in hearing about them. So - 3D export (even with the scary and dreaded STEP), is actually pretty easy. What we are lacking is two simple pieces of data... 1. Outline shape of the board. I do not want to merge the demo code I have, which (crudely) tries to guess at the board outline - much like a fabricator does, by piecing together objects on the magic "outline" layer. This goes firmly against my intentions to produce more "semantic" data in PCB, and less "magic named layer, geometry interpreting heuristics". By all means - we can merge the heuristics, but it needs to be user-activated process that generates the formally defined board-outline based on the data handed to it - not an auto-run process like I currently have in my branch. If it were to auto run to produce the 3D data, we could get to the point where we can _never_ change the heuristic without risking breaking people's output. At least if the user must manually run the heuristic, I can care a little less about whether it _always_ produces the same result from version to version. (The user can decide if they keep the answer or not). 2. Board thickness. So simple solution - define some data-format addition, and/or known-named attribute to specify 2., and add a syntax to throw a polygon definition into the board file for 1. Sadly - I don't like simple :(... and failed to take the easy route on that. Simple doesn't account for flex-rigid stack-ups (different shapes and thicknesses with each stratum), more than 2x outer-layers, I felt that PCB's format is a mess, and that tacking on more advanced concepts without sitting down and having a good think about wider needs / use-cases was not the way to go. AP210 (sorry!) has a layer shape / stratum model which could be sub-set (admittedly it is fairly complex). I guess what I'm saying - is we need to add physical stack-up and outline information to PCB. Get it right, and we solve: a) The physical DRC aspects of blind / buried vias b) Specifying, in a machine-parsable way, the construction of a flex-rigid board c) Specifying in a machine-parsable way, the construction of a conventional PCB board. (Note on c), I believe STEP AP210 actually has a set of entities which can fully define a board stratum set / stackup... and there is a non FOSS, but freely available tool called IDAStep that can view / parse these). I already did some work on extending the polygon representation to include circular arcs (often present in PCB outlines) - we just need some data-structures to tie a PCB "POLYGON" as a stratum outline, define its thickness, and somehow reconcile the physical strata with PCB's "layer stack". (The fact we can have multiple layers which combine to give one physical layer is not a design feature I like, but we're stuck with it). Some of the stratum (core / prepeg etc..) layers will probably need to be auto-generated (assumed geometry), since we don't define their shape in PCB - or perhaps we need to have an "inherit from master board-outline" button somewhere. I'll not be far from being able to generate a _complete_ 3D model of the board (if that level of detail is desired). This is not warranted for simple mechanical / electrical co-design, but (I'm told), would be quite useful for high frequency design / finite element modelling etc.. Peter > Britton