Mail Archives: geda-user/2013/08/29/14:57:44
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
- Raw text -