X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Cam-AntiVirus: not scanned (internal relaying) X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: pcjc2 Date: Thu, 29 Aug 2013 19:57:08 +0100 From: "Peter C.J. Clifton" To: geda-user AT delorie DOT com Cc: Markus Hitter Subject: Re: [geda-user] Thoughts on mechanical CAD interaction... In-Reply-To: <4F0C8F27-B063-44CF-9011-63D2B62F3FD9@jump-ing.de> References: <1377775142 DOT 15398 DOT 1 DOT camel AT pcjc2lap> <4F0C8F27-B063-44CF-9011-63D2B62F3FD9 AT jump-ing DOT de> Message-ID: <3752e7fd48358f6e97a09d34392997aa@cam.ac.uk> X-Sender: pcjc2 AT cam DOT ac DOT uk User-Agent: Roundcube Webmail/0.9.3 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 2013-08-29 14:00, Markus Hitter wrote: > Am 29.08.2013 um 13:19 schrieb Peter Clifton: > >> (Solidworks 2012, rendering a board geometry I created in PCB) > > Hi Peter, > > welcome to the group of 3D-exporter-writers! There's a branch > "LP699502-openscad-exporter" in the git repo already, which adds not > one, but two exporters to OpenSCAD. OpenSCAD can export STL, which > can be imported to SolidWorks and many other CAD applications. The problem with STL is that it only represents a collection of triangles. It cannot faithfull model curvilinear geometry such as drill hole bores, board oulines containing arcs etc.. Clearly OpenSCAD can model such features in its extrusions, but it can't emit that model in a lossless way for other CAD systems to consume. Whilst STL files CAN be imported by CAD systems, most packages (even expensive ones) will not re-approximate the underying features. In the simple STEP examples I have produced so far, you can (for example), instruct the CAD system to perform a concentric mate between a pin hole and a corresponding package pin. (This would not be possible with an STL model, which would just see triangular faces). At the moment, I support extrusions of piece-wise linear and circular contours. (IE.. currently, a board outline containig arcs will be approximated with a piece-wise linear edge). This can (and will) change if I get enough interest, I'm looking forward to adding support for arc segments when I get time (and the knowledge of how to export extrusions of them in STEP). Pure circular contours (e.g. drill holes in the board) are already tracked as such through the polygon handling code, and thus end up as cylindrical faces in the STEP export. With regards the OpenSCAD exporter(s).. I think we can refactor and share some code in approximating the board outline. I have one method included in the experimental GL branch, and I use that for the STEP exporter. I want _ONE_ method of interpreting the "outline" layer into a 2D sketch, and longer term.. I want the definition of that outline to be explicit as such. (A closed edge loop composed of poly-curve segments of line and arc types would be an ideal first step). Clearly, there is already some demand for getting this data out of PCB, so all exporters will benefit from modelling it explicitly. > My knowledge so far is, STEP is a pretty complex description > language, similar to perhaps PostScript. As such it's probably a good > idea to use one of the two existing STEP handling libraries - > OpenCascade or STEPcode - instead of reinventing the wheel. STEP is a rather complex modelling language, but the scope of what it can model is astounding. (It is also the de-facto standard for CAD data interchange, so we cannot ignore it). No wheels are being reinvented here though.. _outputting_ legal STEP representations is a whole lot eaiser than importing 3D models for rendering in PCB's 3D view. (Something I'd love to get to "one day"). OpenCascade is a no-go unless they change their license, and even then - I'm not sure its a perfect fit. STEPcode is a completely different scope, and deals more with the Part21 interchange files we know and love as "STEP" files. It in no way has ANY clue about graphics, geometry, topology or what have you. For the moment, my needs are simple enough that I don't need a library to handle emitting my STEP entities. If I ever wanted to read STEP file data - yes, perhaps a library like STEPcode would be of use. >> For those who are impatient, and want to try it now, you may find the >> code in one state or other in my repo.or.cz repository for PCB. You >> want >> the "step_export_on_local_customisation" branch. > > If I had a free wish, I'd ask you to move this branch to the central > repo, so everybody can test and develop. :-) I won't do that currently, as I do not stick to the "never re-write history" model which is important to us in the official repository. (I use stgit, and that means history changes as I work on feature patches). The repository IS publicly available, so its location is not of real importance for those wanting to test and/or contribute. The main blocking item is that the majority of the branches there are based upon development code which is not clean enough to merge upstream yet. Regards, Peter Clifton