cadquery
cadquery copied to clipboard
CadQuery
Potentially Add Additional cq-kit STEP Export Options to Core
This is a follow-up issue to #1082 so that we can keep track of the idea and decide if we want to expand the options in the future.
STEP export now takes a kwargs parameter that allows any number of options to be passed. Only two were added: write_pcurves and precision_mode, but cq-kit has other settings that might be useful as well. Here's a relevant quote from @michaelgale in the issue.
This is main reason I added alternative STEP export to CQ-Kit--the STEP files with the P-Curves were simply too big. Furthermore, the floating point residue round off of coordinate values also consumed needless bytes resulting in bigger files. More details are in the StepFileExporter class docstring.
Here is a summary of the additional options that we might want to consider.
tolerance: Numerical tolerance or resolution of floating point data, the number of significant figures, e.g. 9 represents 1x10^-9 add_meta_data: Enables or disables writing additional meta data to file. metadata: Dictionary which stores STEP file meta data for HEADER. Used with the above.
There is custom code in the KiCAD model generator that adds the license to the STEP file, but I think the authroization part of the metadata header in cq-kit could serve the same purpose if these options were integrated into CQ core. See the docstring mentioned in the quote above for more information.
-1 on this. IMO better to keep the core lean and not loose focus on integrating yet another exporter. Nothing stopping KiCAD from using cq-kit. As mentioned in another issue, they should really consider using different format and not export the issue to another project.
they should really consider using different format and not export the issue to another project.
What would the motivation be for the KiCAD project to move away from STEP format to something like the brep file format? If a user downloads a 3D model from a vendor's website it will be in STEP format, and other tools in the ecosystem (including manufacturer websites) would be much more likely to accept STEP than any other format.
better to keep the core lean and not loose focus
Adding a few parameters to an existing method doesn't feel like a loss of focus or less clean to me, as long as they are generally useful and not KiCAD specific. Specifically, tolerance, add_meta_data, and metadata seem generally useable and useful by all, so +1 from me for adding those.
I'm not sure if others are proposed or not.
It's not about the parameters, but the implementation. Tolerance is not handled by OCCT AFAICT.
they should really consider using different format and not export the issue to another project.
What would the motivation be for the KiCAD project to move away from STEP format to something like the brep file format? If a user downloads a 3D model from a vendor's website it will be in STEP format, and other tools in the ecosystem (including manufacturer websites) would be much more likely to accept STEP than any other format.
Well, STEP import/export is not related to the internal representation of the models used by the CAD kernel. One can use the internal representation (that saves space) and still be able to import/export STEP.
BTW: I assume here that KiCAD is the main motivation for opening this issue. Please correct me if I'm wrong.
Well, STEP import/export is not related to the internal representation of the models used by the CAD kernel. One can use the internal representation (that saves space) and still be able to import/export STEP.
in KiCAD's use case, IMO using an interchange format, rather than the native representation, is absolutely the right call. It's not reasonable to assume that all users of KiCAD with interest in the models would have OCCT-based software. Yes, KiCAD could provide functionality to export them as needed in STEP, but that's an extra step for the user, and that would be a huge departure from KiCAD's current system.
Adding extra (optional) arguments to the exporter is a modest change, especially if it's confined to write_pcurves and precision_mode since these are simply handed off to the existing OCCT core for implementation.
Adding features such as header meta data and cleaning up the floating point precision/tolerance would require additional code for implementation. I would say that the header meta data is the most desirable since it allows creators to add meaningful titles and traceability to objects when used in other CAD applications.
As a minimum, the write_pcurves argument should be exposed since it offers the most significant value to end users with a dramatic reduction in result STEP file size.
BTW: I assume here that KiCAD is the main motivation for opening this issue. Please correct me if I'm wrong.
KiCAD and FxBricks both use the ability to turn off pcurves and attach metadata (including license data). The addition of license data is currently handled by code within the KiCAD generator codebase (not by CQ or cq-kit).
The question of storage format (brep vs step) will become less critical eventually because KiCAD wants to generate STEP and VRML files on demand using CadQuery. Once that happens KiCAD won't have to bundle gigabytes of model files, many of which a user will never need.
If certain functionality is always going to be relegated to CQ extensions, we need to define where the line is between the core and extensions, and we need to find ways to make it less difficult for users to know what extensions they need to perform certain tasks (I.e. a much more thorough and first class cadquery-plugins repo). Ways to ensure that extensions have all the functionality in the core that they need will be important too.
+1 for @jmwright for pointing out most electronic component manufacturers offer STEP models of their components for integration in a combined EDA/CAD workflow. I use this all the time by combining populated PCB models from KiCAD with CQ generated enclosures. Since KiCAD uses STEP models for components, I can build STEP models for custom KiCAD library components using CQ--its really really useful.
Just for a point of comparison, I imported one of our CQ generated models and exported both a P-curve and non P-curve variant: 9.8 MB NoPCurves.step 23 MB PCurves.step These economies of file size dramatically add up--especially for automated model generation at scale for users such as KiCAD
Just to be clear that we are discussing the same thing: I'm stating that it makes more sense to use the native format internally by the application. It has no relation with STEP import or export for the users. Could you clarify what do you mean with "extra step for the user" @dcowden ?
czw., 2 cze 2022, 16:10 użytkownik thebluedirt @.***> napisał:
Well, STEP import/export is not related to the internal representation of the models used by the CAD kernel. One can use the internal representation (that saves space) and still be able to import/export STEP.
in KiCAD's use case, IMO using an interchange format, rather than the native representation, is absolutely the right call. It's not reasonable to assume that all users of KiCAD with interest in the models would have OCCT-based software. Yes, KiCAD could provide functionality to export them as needed in STEP, but that's an extra step for the user, and that would be a huge departure from KiCAD's current system.
— Reply to this email directly, view it on GitHub https://github.com/CadQuery/cadquery/issues/1094#issuecomment-1144912829, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKVOYV7HS3AJKNAMQFKLOLVNC6EXANCNFSM5XQXEFZA . You are receiving this because you commented.Message ID: @.***>
Could you clarify what do you mean with "extra step for the user"
@adam-urbanczyk In today's way of working, KIcad 'comes with' a bunch of STEP files already created. if a user wants to get a step file, they have the file ready, they just copy it off the filesystem (i think). If KiCAD used an internal format of brep, then the user will have to take some action to trigger the conversion to produce STEP files. that action is what i'm referring to as the extra step.
if we are talking about the 'internal' format in the purest sense, then that would be the cq source code. a brep format would serve value only as a cache essentially-- a way to start without re-executing the source. STEP can serve the cache use case-- but can also serve for file exchange, which OCC brep can't
Could you clarify what do you mean with "extra step for the user"
@adam-urbanczyk In today's way of working, KIcad 'comes with' a bunch of STEP files already created. if a user wants to get a step file, they have the file ready, they just copy it off the filesystem (i think). If KiCAD used an internal format of brep, then the user will have to take some action to trigger the conversion to produce STEP files. that action is what i'm referring to as the extra step.
if we are talking about the 'internal' format in the purest sense, then that would be the cq source code. a brep format would serve value only as a cache essentially-- a way to start without re-executing the source. STEP can serve the cache use case-- but can also serve for file exchange, which OCC brep can't
Uhm are you sure? What is the point of copying of individual footprints (as opposed to complete PCB assy which has to genereted irregardles of storage format)?
Uhm are you sure? What is the point of copying of individual footprints (as opposed to complete PCB assy which has to genereted irregardles of storage format)?
No, im not sure, i do not do these workflows.
No offense meant, but I don't think the standard of accepting a contribution is that we can prove that there's no other way for people to get the job done without it. Clearly, KiCAD could avoid STEP.
@jmwright and @michaelgale have made reasonable arguments that two big users of CQ, KiCAD and FxBricks, would benefit from this functionality. The counter arguments are that adding these parameters make the code 'un-lean' and 'unfocused' . I do not understand the unlean argument. Can you give an example of the 'fat' that would be added by these suggestions? The definition of 'unlean' is , i think, colloquially 'unneeded code'.
i understand but simply don't agree with the unfocused argument, because the suggested options seem reasonably applicable to many users, not just KiCAD.
Uhm are you sure? What is the point of copying of individual footprints (as opposed to complete PCB assy which has to genereted irregardles of storage format)?
No, im not sure, i do not do these workflows.
No offense meant, but I don't think the standard of accepting a contribution is that we can prove that there's no other way for people to get the job done without it. Clearly, KiCAD could avoid STEP.
@jmwright and @michaelgale have made reasonable arguments that two big users of CQ, KiCAD and FxBricks, would benefit from this functionality. The counter arguments are that adding these parameters make the code 'un-lean' and 'unfocused' . I do not understand the unlean argument. Can you give an example of the 'fat' that would be added by these suggestions? The definition of 'unlean' is , i think, colloquially 'unneeded code'.
i understand but simply don't agree with the unfocused argument, because the suggested options seem reasonably applicable to many users, not just KiCAD.
AFAICT what cq-kit does is implementing a custom (re)exporter and not using functionality already present in OCCT. That is the 'unlean' part.
As discussed extensively thete are better ways of solving the KiCAD-specific problem of storing large number of models efficiently. Binary storage will be intrinsically better than text-based.
ok I'm going to try to sum up the current situation
- cq-kit has richer functionality for STEP support than cq-core
- two options, write_pcurves, and precision mode, were recently added to core, because they (a) help make files smaller and (b) are flags available in OCCT
- @jmwright proposes adding functionality to enrich cq-core created STEP files with optional metadata. This is not done in OCCT, so the implementation would probably look like taking the STEP file that is created by OCCT, and then doing other operations on it ( in this case, adding metadata)
- @adam-urbanczyk is against this addition for two reasons: (a) it feels to him like KiCAD could solve this problem themselves in a variety of ways, one being to discontinue using STEP (the lean argument) , and (b) it will distract core resources from other tasks ('focus')
Do i have this right @jmwright and @adam-urbanczyk ?
Do i have this right?
@dcowden I think that's probably a good summation. As I stated in my original post, this issue was created to "...decide if we want to expand the options in the future." If there is a concensus (which it seems there is not yet) that we leave the other options out (or put them in), then it's fine with me either way.
I think that what is making this discussion more challenging is that there is a lack of clarity/concensus on what is in bounds for CQ core, and what should be left to extensions. This is a discussion the core dev team has never had. Is it possible to clearly define and articulate that boundary between core and extensions? Without something like that we're always going to be going in circles because the line is arbitrary and will vary by developer.
@jmwright i agree with you completely, and I have some thoughts, but first @adam-urbanczyk can you comment on whether i've summarized your concerns correctly?
Almost, I think 3 should be adding metadata and changing numerical precision.
ok thanks @adam-urbanczyk .
Ok i do agree with @jmwright that the discussion we should have is more broad than just this issue. I'm not sure this issue is the place to have that conversation. And in fact, maybe a more interactive medium like discord would be better suited. @jmwright @adam-urbanczyk what do ya'll think? Discord? email thread? other?
A thread on the discord could be a suitable place, I second this as I would be interested to discuss what CQ wants to be / should be as well as the roadmap for it !
thanks Jojain, yes sorry for impliying we would not include all core devs and intersted parties-- this does seem like a very good time to get some planning and rules of engagement hammered out.
This is a very , very good problem to have, and I'm thankful we've gotten there!
I won't be able to join in the coming weeks. TBH I also won't be contributing a lot in the foreseeable future, so maybe better reach a conclusion without me.
ok thanks @adam-urbanczyk we'll discuss and i'll share notes-- actually i suspect we'll publish a document capturing the ideas and discussion
What would be the "extra step for the user"?
czw., 2 cze 2022, 16:10 użytkownik thebluedirt @.***> napisał:
Well, STEP import/export is not related to the internal representation of the models used by the CAD kernel. One can use the internal representation (that saves space) and still be able to import/export STEP.
in KiCAD's use case, IMO using an interchange format, rather than the native representation, is absolutely the right call. It's not reasonable to assume that all users of KiCAD with interest in the models would have OCCT-based software. Yes, KiCAD could provide functionality to export them as needed in STEP, but that's an extra step for the user, and that would be a huge departure from KiCAD's current system.
— Reply to this email directly, view it on GitHub https://github.com/CadQuery/cadquery/issues/1094#issuecomment-1144912829, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKVOYV7HS3AJKNAMQFKLOLVNC6EXANCNFSM5XQXEFZA . You are receiving this because you commented.Message ID: @.***>