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 >> <[email protected] <mailto:[email protected]>> 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
