On Tue, Jun 10= , 2014 at 1:12 AM, Peter Clifton <pcjc2 AT cam DOT ac DOT uk> 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 partic= ularly
robust, and with the current code, can lead to incorrect dimensioning.
(I trace the polygon produced by gluing "fat" versions of the &qu= ot;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. =C2=A0I really don't want to lock in rules to guestimat= e the
user's intent by looking at a drawing layer, when an exact outline coul= d
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=3D0, and the bottom at
Z=3D-1.6mm. More sensible alternatives would be to centre the board
stack-up about Z=3D0, place or the bottom of the board at Z=3D0.

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 extrac= t
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 <