Assembly3 preview

[saso]

In both cases this are actually just two solids inside a part.

then the actual importer is doing fine.

In this simple case (two solids inside a part) it is doing ok, yes

And does it sound useful to add a Body container and place a solid inside a Body, considering that FC Body doesn't allow inside a simple Solid?
https://www.freecadweb.org/wiki/PartDesign_Body/en

It can seem to be useless to have additional bodies and groups (geometrical sets in catia) when we have such simple examples (just two solids inside one part), but they start to become very useful when you have hundreds of elements inside one part, because they help to group and manage them. But as I have argued before our implementation of bodies in FC is IMO wrong. They behave similar like Part containers but should actually behave more like Groups.

I think what at the moment is implemented is a good representation of the STEP structure (STEP doesn't have any history of the included shapes).
It can be sure improved, but I think the 'Part' container for the hierarchy is the right one to be used as it is implemented now.

No, because we don't have a proper Assembly container. So the simple example works ok because it has just one part (no assemblies), the larger example is however all wrong. One does not put part containers in to part containers and one does not put geometry directly in to assembly containers (well we could debate about this in the future, but I would strongly prefer if we first implement the proper basic architecture of assemblies and parts).

This is how the second larger example should look in FC if we would have a proper implementation of the assembly container (note that I had to change all the parts to assemblies and add additional parts for all the solids and that there are no bodies, but it would also be ok if there would be or personally I would say that it would be even better ). And if you compare this now to the 3DAnalyzer or catia tree (or actually to any other parametric cad) you will see that things are as they should be.

Untitled.png (192.35 KiB) Viewed 1684 times

[easyw-fc]

But as I have argued before our implementation of bodies in FC is IMO wrong.

as I said before, you have to start a different thread for asking a different Body implementation, if you consider this a feature.
Or just revamp your old thread I already pointed out:
https://forum.freecadweb.org/viewtopic.php?f=8&t=26357

Here we need to map the STEP structure to what FC can handle.

About the Assembly part, I don't see the issue ATM. STEP files don't have any history at all of the included shapes...
Adding option to different loading mode could be interesting, but it can be done later;
moreover you need to get a developer consensus to change what Body can be/done.

As I said the structure may be improved, but Part container is doing a good job for STEP hierarchy ATM.

[saso]

I am mostly ignoring the body discussion in this topic, but assembly containers, part containers and bodies are closely related, they have to be discussed together because only together they give you the full picture and the proper full implementation of the hierarchical structure. Even if you are for some reason happy with such imports as we have now (you should not be), how will you properly export this if you have only parts containers and all other cads are expecting the assemblies and parts hierarchy? This is also the reason why cad programs that don't support bodies have to get "creative" when importing multi-body steps, because they don't have the full hierarchical structure to properly import them.

[saso]

I am mostly ignoring the body discussion in this topic, but assembly containers, part containers and bodies are closely related, they have to be discussed together because only together they give you the full picture and the proper full implementation of the hierarchical structure. Even if you are for some reason happy with such imports as we have now (you should not be), how will you properly export this if you have only parts containers and all other cads are expecting the assemblies and parts hierarchy? This is also the reason why cad programs that don't support bodies have to get "creative" when importing multi-body steps, because they don't have the full hierarchical structure to properly import them.

And it is this hierarchical structure what "an assembly" is, not the constraints. Of course the constraints can then be applied on to it, but they can be applied on the Sketcher level (between the 2d geometry of the sketcher), on the Part level (between the geometry in a Part) and on the Assembly level (between the parts). But all of this should not be just mixed together because this is actually a simple structure and this simplicity gives the possibility to create huge complex models (you repeat a simple thing again and again and again...).

[realthunder]

As I said the structure may be improved, but Part container is doing a good job for STEP hierarchy ATM.

Have you tried my suggestion of round-trip testing with DSM. You open the UR10 STEP in upstream, export again as STEP, and then open that STEP in DSM. You'll find that the hierarchy is changed a lot. In STEP file, saving as simple shape or as assembly uses different syntax. With UR10, all those joints are saved as simple shape, not assembly. We can't use the same container for both the assembly and simple ship, or else the exporter will be confused and change the output hierarchy like what upstream does.

I'll use Part::Compound for mult-solid shape because the lack of better alternatives in current FC, but at least it can pass round-trip test. I'll release a new version soon.

[easyw-fc]

Have you tried my suggestion of round-trip testing with DSM. You open the UR10 STEP in upstream, export again as STEP, and then open that STEP in DSM. You'll find that the hierarchy is changed a lot. In STEP file, saving as simple shape or as assembly uses different syntax. With UR10, all those joints are saved as simple shape, not assembly. We can't use the same container for both the assembly and simple ship, or else the exporter will be confused and change the output hierarchy like what upstream does.

I said is doing a good job, not perfect but extremely superior to what we had before for years (a flattened structure).

I'll use Part::Compound for mult-solid shape because the lack of better alternatives in current FC, but at least it can pass round-trip test. I'll release a new version soon.

That would be a wrong decision IMO. Compound is doubling the shapes as Jean Marie already pointed out in his refactoring path.
Then huge assembly will weight double and will not be easy to handle. Your branch is missing already the VBO optimization that is in use ATM.
I would prefer a lost of assembly structure, but this is also what CAD Assistant of OCC is doing, instead of a poor performance in file handling.
I would suggest you to discuss a new container with the devs instead of introducing Compound container, already dropped before.
Moreover I also would suggest you to rely on real commercial CAD for comparison instead of DSM, which is a not widely diffuse CAD.

[realthunder]

That would be a wrong decision IMO. Compound is doubling the shapes as Jean Marie already pointed out in his refactoring path.
Then huge assembly will weight double and will not be easy to handle.

Of course, I've considered this. Come on, I'm the Link guy. And I have stated many times that one of the main problem I have with upstream importer is that it multiplies the file size when importing with hierarchy. But you are okay with this? Hmm... Anyway, I added Part::Compound2, which is like Part::Compound, but its Shape is marked as transient, meaning it is not saved, but rebuilt when restoring. BTW, it won't slow down much when restoring. In fact it will be faster, as reading BREP file is most likely slower than compounding list of shapes.

Your branch is missing already the VBO optimization that is in use ATM.

How many platform have you tested? Any consideration on difference in graphics card? I tested on both Linux and Windows, although both of the machine uses Intel embedded graphics card. There is obvious boost when VBO is enabled in both upstream and mine branch, no obvious performance difference between the two. With huge model, the upstream imported model will put stress on graphics memory, because of all the duplication. The initial VBO buffering will slow system down.

BTW, I've fixed frame rate display, too. It is much more responsive now.

[easyw-fc]

Of course, I've considered this. Come on, I'm the Link guy.
...
Hmm... Anyway, I added Part::Compound2, which is like Part::Compound, but its Shape is marked as transient, meaning it is not saved, but rebuilt when restoring. BTW, it won't slow down much when restoring. In fact it will be faster, as reading BREP file is most likely slower than compounding list of shapes.

Come on, you are repetitively adjusting your coding because of this discussion, so 'Come on' this is positive at the end.

Your branch is missing already the VBO optimization that is in use ATM.

How many platform have you tested? Any consideration on difference in graphics card?

We (Jean Marie and I and others during his refactoring) have tested VBO on Win, Linux and OSX. So at least a platform more than you tested and with different Graphic cards.

I tested on both Linux and Windows, although both of the machine uses Intel embedded graphics card.

then you haven't real tested any GPU advantages

There is obvious boost when VBO is enabled in both upstream and mine branch, no obvious performance difference between the two. With huge model, the upstream imported model will put stress on graphics memory, because of all the duplication. The initial VBO buffering will slow system down.

BTW, I've fixed frame rate display, too. It is much more responsive now.

So again you are adjusting the code because of this discussion...

I am the guy the promoted your work on KiCAD, and did a readme of your project that was just unknown by users...
https://github.com/realthunder/fcad_pcb/pull/3
https://forum.kicad.info/t/exporting-pc ... em/10150/7

and what about the links? Was I the only who tested them and implemented some code to test/use them or not?

Thx a lot for this amazing new Assembly

And I want to thank you for testing. You're probably the first one to try development using my branch.

and what about also promoting your work here:
https://forum.freecadweb.org/viewtopic. ... 20#p234291
and what about pointing you to the right user case and documentation for STEP standards?
https://forum.freecadweb.org/viewtopic. ... 10#p233650

You miss the vision... I'm not against you nor against the changes...
I'm here to try to improve FC interoperability... I started my work years ago and I want to continue on this...

I just don't care if you consider this against you or your work, but we are on the same ship, also if you don't want to admit it.
Cheers
Maurice

[realthunder]

New version released.

New options are exposed through STEP import preference page. To use the upstream importer, unselect 'Use LinkGroup'. The program auto selects which exporter to use. The criteria of using upstream exporter is the selected object hierarchy contains at least one App::Part, and no Link related objects.

After import, the report view will print read time, import time, and total time. 'Read' is handled entirely by OCCT, which are the same for both the upstream and my importer. The difference will be at the 'import time'.

Screenshot from 2018-06-08 20-53-14.png (68.47 KiB) Viewed 1631 times

[easyw-fc]

New version released.

first testing using A3 branch and Links:
1) import this file on the list I suggested at CAX-IF org:
https://www.cax-if.org/library/as1-pe-203.zip
2) try to export it ... FC just hangs for ever without ending the export process..

If you repeat the process with Links disabled import and export are fine.

New options are exposed through STEP import preference page. To use the upstream importer, unselect 'Use LinkGroup'. The program auto selects which exporter to use. The criteria of using upstream exporter is the selected object hierarchy contains at least one App::Part, and no Link related objects.

For a better comparison, would it be possible to have also an option to convert the Links to only Part containers when exporting the file?