kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

On 16.06.2015 14:16, Wayne Stambaugh wrote:
> On 6/15/2015 9:20 PM, Cirilo Bernardo wrote:
>> On Tue, Jun 16, 2015 at 8:33 AM, Tomasz Wlostowski
>> <tomasz.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>> wrote:
>>
>>     On 14.06.2015 13:35, jp charras wrote:
>>     > Le 14/06/2015 12:01, Tomasz Wlostowski a écrit :
>>     >> On 14.06.2015 02:35, Cirilo Bernardo wrote:
>>     >>> 7. STEP: (future plans) the plugin will only provide an Export
>>     >>
>>     >> I'd also like to add STEP visualization in the near future (post-stable ofc)
>>     >>
>>     >> Tom
>>     >>
>>     >> PS. It is possible to export a hierarchical assembly in STEP from OCC.
>>     >> No need to write a special library for that.
>>     >
>>     > We all agree (at least guys like me who make designs with very strong
>>     > mechanical constraints) step import/export is a major feature.
>>     >
>>     > However, OCC is a very heavy dependency for Kicad.
>>     > I am not especially thrilled by OCC dependency.
>>     Jean-Pierre,
>>
>>     OCC is at least a complete thing. It can read/write STEP, provides all
>>     boundary representation algorithms we need for making a PCB model from
>>     layout (extrusion, boolean ops, chamfering/filleting) and can
>>     triangulate BRep items for rendering purposes. Moreover, OCC despite
>>     being big is pretty self-contained, it brings no additional
>>     dependencies.
>>     >
>>     > If stepcode is usable, this is a (by far) preferable dependency, even it
>>     > is not perfect.
>>
>>     The above is not true for stepcode - AFAIK it only reads/writes STEP,
>>     but has no geometry algorithms which we would need to take from other
>>     libraries.
>>
>>
>> That's correct; stepcode is only a "preprocessor" - it will read or
>> write data
>> and ensure that the file conforms to standards specifications but it is
>> entirely ignorant of what the data means. Everyone needs to add their
>> "postprocessor" and "application code" to interpret or place data into the
>> STEP object.
>>
>> Tom, have you got a small example of an assembly created by OCC?
>> I would like to see how SolidWorks imports the file and if the results
>> will be acceptable. From what I could read, OpenCascade offer the
>> software to manage assemblies as a paid extension and from the
>> documentation in OCC I couldn't work out how to extract or create
>> hierarchical information.
>>
>> As for rendering STEP models that would certainly be a large task if we
>> did it ourselves, but I believe the SISL library contains all the algorithms
>> we need to calculate vertices and the painful details of rendering are a
>> matter of interpreting STEP data to determine the vertices on surfaces
>> and their boundaries. Still, if OCC will do the job I would concede that
>> such a large dependency may be worthwhile since we can concentrate
>> on other aspects of KiCad rather than having our time dedicated to
>> reimplementing something which is already freely available.
> 
> If we use OCC, it needs to be an optional dependency.
Sure (PS.b y IPC I meant a separate kiface dealing with mechanical I/O
and providing meshes for the 3D viewer.)

  I don't have any
> experience with OCC and how easy it is to build on other platforms so
> initially I would require that it be a build option.

On Linux:
git clone https://github.com/tpaviot/oce
cmake
make


> 
> Also, I know to some of you I sound like a broken record but none of
> this can happen until the underlying 3D model library code is fixed.

Fully agree. AFAIK Mario was volunteering to work on the 3D models?

Tom