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: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Message-ID: <1402355532.14291.63.camel@pcjc2lap> Subject: [geda-user] Prerequisites for a STEP exporter - call for assistance. From: Peter Clifton To: geda-user AT delorie DOT com Date: Tue, 10 Jun 2014 00:12:12 +0100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com Hi All, Some might recall that I was looking into 3D export for PCB. (Of the board shape). My thanks go out to the people who funded purchase of the ISO STEP standard collection - this work would not have been possible without the reference material. Whilst progress on the exporter has been very slow going, it is a lot closer to being useful now. I've re-written my export code over the last week or so, and can now emit useful AP214 .STEP files containing a representation of the PCB board, complete with via holes. (And colour!) As of tonight, there is support for emitting multiple solid bodies, when the board outline has more than one piece. There are, however, some things we ought to get straight in PCB before the exporter can sensibly be finished off and merged. 1. We need a semantically defined, machine parse-able board outline definition adding to our file format. I propose that we allow users to draw this contour in a similar way to a polygon, and use this as a machine-readable "outline" embedded in the PCB file. For my testing, I have been extracting an outline polygon from the objects on the "outline" layer. Unfortunately, this is not particularly robust, and with the current code, can lead to incorrect dimensioning. (I trace the polygon produced by gluing "fat" versions of the "outline" layer objects in order to allow skipping over small gaps in their centrelines). In order to do this properly we need to develop an extended poly-curve syntax which allows line AND arc segments to form a connected, closed loop. With this, the user can be completely explicit about the design intent. I DO NOT want us to extract this from the magic "outline" layer, using some magic heuristics to interpret what various objects the user drew there. We should use this extended poly-curve definition to replace the poly-line outline definition used of PCB's (file format) polygons. The underlying polygon algebra code will internally use line-segment approximations to implement the arc segments, but we need to be able to express the design intent to use arcs as part of the board outline. (The STEP exporter will certainly be able to use them). With a common poly-curve format, we can, of course use the (extended) polygon editing code to define an explicit board outline. Exporters and renders which care (gerber, STEP, PCB+GL), can use this definition to emit definitive outline data. We could possibly write an action routine to extract an outline from lines and arcs on an existing, legacy "outline" layer. This could perhaps be based on an extension of the outline extraction code I've been using to test PCB+GL and the STEP exporter, although a slightly different approach to constructing the outline polygon would be needed to have it properly follow the centreline of the various lines and arcs. I am, however, COMPLETELY DEAD AGAINST using an automatic extraction routine to add (yet more) magic and rules to the existing concept of an "outline" layer. Until we have "PROPER" outline information in the PCB file, there is no point in merging my STEP exporter, or the PCB+GL features which use the board outlines. I really don't want to lock in rules to guestimate the user's intent by looking at a drawing layer, when an exact outline could so readily be defined explicitly. 2. We need to define and store stack-up meta-data, at the very least - board thickness. (In a defined, and machine parse-able way). Ideally, we could store full build-up information, as this would be useful for the 3D view, and for any (FUTURE) more detailed 3D model output, that could conceivably include tracking and layer build-up. 3. If we start defining "courtyard" and Z-height as part of our footprints, then I can start extruding those outlines as well... to augment the board model. This is a more trivial file format extension once we have a poly-curve loop primitive. 4. We need a decision on coordinates. Currently, my export uses a right-handed coordinate system with its origin at the bottom left of the board, with Z+ being towards the top of the board, coming out of the screen. This is in common with the gerber exported coordinates (in 2D at least), and TBH - is a more sane coordinate system than PCB currently uses. For now though, we will have to convert on the fly. We do, however, need to define the Z-planes. At the moment, perhaps not quite right, I have the top of the board at Z=0, and the bottom at Z=-1.6mm. More sensible alternatives would be to centre the board stack-up about Z=0, place or the bottom of the board at Z=0. I, unfortunately, don't have the time or resources to address points 1, 2 (and 3) at the moment, so I'm calling for some assistance. Does anyone want to look at these problems, work on the file-format extensions, and editing tools to allow such definitions??? In my opinion, the 3D stuff is easy (once you've got your head around some of the STEP standard). It is also not too not critical in terms of risk leaving a legacy to maintain compatibility with, should incorrect design choices be made). The hard problem is getting good data to work with. Getting the data-model and file format right is the difficult task.. we don't want to be stuck maintaining backwards compatibility with bad design decisions here. That is the primary reason why I don't want to introduce code to extract an outline curve from the "outline" layer, and why merging the 3D stuff is not going to be a quick job. Does anyone feel like a challenge? Best regards, -- Peter Clifton Clifton Electronics