Mail Archives: geda-user/2014/06/10/17:00:59
Peter Clifton wrote:
> 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,
>
>
Hi Peter,
I might find some spare cycles in the near future.
Depending on what parts to do and when needed (road map please).
It might be a good idea to start a topic branch "devel" for this
development on the upstream repo.
Maybe we need a "wall" for scribbles on the Launchpad bug report system
to stay in sync with other developers and contributors.
Maybe we need to get organised at IRC #geda on regular time slices (EU
and/or US time zones ?), and have code sprints.
Or remain with "business as usual" ;-( and have 1 accidental commit
per month (me thinks not funny !).
I'm not very strong with C coding skills or "managing" software
projects, maybe documenting stuff and bug hunting.
I do know that development on pcb is on the brink of stalling, so FWIW,
I will put my shoulders under this initiative.
On to pcb-4.0 !!
Kind regards,
Bert Timmerman.
- Raw text -