Part module preference option not activated at startup ?

[Jee-Bee]

I also vote to leave the old, plain Part step importer in place. That's one of the great features of FreeCAD to have several importers/exporters for a file type. It would be a pity to cut into that!

What is the advantage to have multple importers?? one importer with multiple configurations(component structure/ Color/ etc) i understand but not why multiple importers.
I understand that independent of the workbench you can always import a step/.../.. file but that should still be possible with a single importer...

[easyw-fc]

I also vote to leave the old, plain Part step importer in place. That's one of the great features of FreeCAD to have several importers/exporters for a file type. It would be a pity to cut into that!

What is the advantage to have multple importers??

I think is intended as two different routines called by the importer, one routine will execute the old plain importer and the other will execute the new hierarchical importer. The way in which is selected one way or the other can be on preferences basis or on dialog checkbox/extension basis

[vejmarie]

I am a little bit lost on what should be the best option. Roughly to have written most of the new importer, both code rely on the same "process" as they are all relying on Open Cascade. If one of them was using a different backend I could see the interest, but keeping two codes and maintaining them to do the same thing is disturbing. By the way it roughly means that I can make behave the new importer the exact same way than the older.

What could be perhaps good if we keep both of them which is fine with me as this seems to be the majority option, I think we shall try to get there code into the same module, took me some time to understand how STEP import was implemented because there is code in Import and Part which are doing the same thing. We shall either merge Import into Part or get the code from Part out of Part and move it into Import. This could at least simplify the maintenance for our next generation developers.

If we don't do it, I will at least add some comment into the new Importer code to refer to the one into Part, just to be sure that somebody can understand how all of this is setup.

[triplus]

Having a checkbox in Preferences for "Preserve assembly structure" and "Preserve color information" should likely address the feature parity request. Do you plan to provide Python API? That is for the users being able to use the STEP import/export procedure from Python? Having that would enable the end users to easily create a set of macro commands and by each having different configuration on how the STEP import/export process should happen. Basically STEP related import/export FreeCAD functionality enabled for the next 15 years!

P.S. As a side effect of your work this basically is the first upstream and user ready FreeCAD Assembly related feature. It's finally happening!

[easyw-fc]

Having a checkbox in Preferences for "Preserve assembly structure" and "Preserve color information" should likely address the feature parity request. Do you plan to provide Python API? That is for the users being able to use the STEP import/export procedure from Python? Having that would enable the end users to easily create a set of macro commands and by each having different configuration on how the STEP import/export process should happen. Basically STEP related import/export FreeCAD functionality enabled for the next 15 years!

this is already available
I have already modified my kicad StepUp macro to export an assembly of the board and parts
and the exporting macro could set the preference variables to export as desired

P.S. As a side effect of your work this basically is the first upstream and user ready FreeCAD Assembly related feature. It's finally happening!

in fact this is a great achievement and it was a weakness of FC import/export feature not present anymore

[triplus]

this is already available
I have already modified my kicad StepUp macro to export an assembly of the board and parts
and the exporting macro could set the preference variables to export as desired

Great!

[wmayer]

I might be wrong but why does it allow to import/export a rather lightweight dataset that the regular importer/exporter can't do ?
I will check the placement issue you reported, that shall be "easy" to fix.

Because the import/export only considers the actual geometry and ignores colors and labels and furthermore puts the whole geometry into a single shape.

I understand that independent of the workbench you can always import a step/.../.. file but that should still be possible with a single importer...

The advanced STEP import/export is accessible via the general File -> Open or File Import/Export functions and drag and drop while the simplified version is only accessible in the Part workbench over the Part menu. So, it actually doesn't collide with the general mechanism.

I am a little bit lost on what should be the best option. Roughly to have written most of the new importer, both code rely on the same "process" as they are all relying on Open Cascade. If one of them was using a different backend I could see the interest, but keeping two codes and maintaining them to do the same thing is disturbing. By the way it roughly means that I can make behave the new importer the exact same way than the older.

The effort of maintaining the simplified version is basically zero -- unless the API of the OCC changes but the function itself doesn't need to be changed.

What could be perhaps good if we keep both of them which is fine with me as this seems to be the majority option, I think we shall try to get there code into the same module, took me some time to understand how STEP import was implemented because there is code in Import and Part which are doing the same thing. We shall either merge Import into Part or get the code from Part out of Part and move it into Import. This could at least simplify the maintenance for our next generation developers.

The advanced STEP import is based on OCC's OCAF framework which depends on a lot of other libraries and even includes X stuff on Linux. That's why its code has been moved to the Import module to avoid that Part depends on all these additional libraries and thus makes its usage on e.g. pure servers more complicated.

[vejmarie]

By the way, there is an Import module, I think I might just put that stuff there. I think we also need to change Part -> Import STEP code to the Import->Step code, as there is no reason to have 2 differents path to do that.

I don't think the "Import Step" in Part should be removed because:

• it still allows to import/export a rather lightweight data set if needed
• it can be used as reference for the high-level STEP import/export to find out erroneous behaviour

Saying the latter I have found a couple of major regressions with the latest changes:

• when exporting a single object (which is not inside a Part container) placement is lost
  Create a cube -> change its placement -> export -> import -> it's now at a different location
• Color information is not read any more in some cases
  Load the model asd.stp from this posting https://forum.freecadweb.org/viewtopic. ... 221#p82369 The black and white parts are set to the default color. And even if a manually set the colors again, export and import they don't come back.
  Not sure if this is an issue as well but with previous versions it had four objects in the tree view while now it's a single object.

Hi wmayer. The 2 bugs reported there shall be fixed within the next couple of hours . A new StepUp version from easyw is also coming up. The placement stuff is stupid implementation issue within XCAF which requires to export a full hierarchy with a root node. The issue is that when we are exporting a single shape, that is not a hierarchy. So I roughly looked for Free Shapes into the XCAF doc after having generated it, and update them with absolute placement, which is now behaving like FreeCAD was before. The Color issue is soon fixed since my latest PR.

Enjoy summer !

[wmayer]

The 2 bugs reported there shall be fixed within the next couple of hours

Thanks! It works like a charm.

[wmayer]

Just found another issue. When you create a Part container, set its placement and add some shapes then on export the placement is ignored. After moving the Part container into a second Part container and selecting the latter for export the placement is considered.

So you always need two Part containers which seems a bit odd behaviour to me.

Any opinions?