Assembly3 preview

[realthunder]

but I have the following issues:
1) the tree has wrong labels

The 'wrong' label is because the software generated the STEP didn't save the instances name. It depends on if this 'wrong' label is auto inserted during STEP generation or OCCT importing. There is nothing we can do at the importer if it is the former. I'll modify the code to disable OCCT import auto naming, and better handle the later case.

The reason why upstream importer appears to be right is because it only uses the base feature name, never the instance name. And if that instance name contains important information, then I'd say the upstream importer is wrong. For example,
For both https://www.cax-if.org/library/as1-oc-214.zip and https://www.cax-if.org/library/as1-tu-203.zip, the upstream importer gives name as

Screenshot from 2018-06-06 07-39-52.png (8.95 KiB) Viewed 2006 times

For my importer, the names are different

Screenshot from 2018-06-06 07-38-38.png (7.88 KiB) Viewed 2006 times

Screenshot from 2018-06-06 07-45-14.png (8.1 KiB) Viewed 2006 times

2) the tree has a totally wrong hierarchy (please note that UR_10 file is generated by SolidWorks and not by an OCC derivative sw as arietta file is)
(it seems your parser has difficulties with non OCC files)

Do you know the original hierarchy in SW? You can't really judge solely by the complexity of the hierarchy. Those unexpanded object are not expanded by my importer because they are saved as compound with no child object naming information. The upstream import does expand the compound but flatten to only one hierarchy, and it only extracts solid and shell, while discarding all the others, which is why you have problem with edge in your other file. You can check inside the hierarchy to confirm that all children names are auto generated. The actual hierarchy in the compound can be much more complex. I plan to add a general Part command to let user manually expand/collapse compound shape.

I made also a comparison between the 'barreleye' huge file:
loading time is similar A3-0.6.1 328sec vs 399sec,
but frame rate are A3-0.6.1 2.1fps vs. 6.8fps

The loading time is off. I have repeatedly tested on my computer, and it always takes about 190 with my importer, and 310 with the upstream. Have you considered the file cache effect? There are really two stages of importing. One big part is the file reading, i.e. the one with the progress bar, which are solely handled by OCCT. The other stage makes FC appears to be frozen. And that is the actually processing time of the importer.

The frame rate is also off. I do notice that the frame rate reported is not always accurate. In my computer it is the upstream sometimes stuck at 2fps, and I'll have to manually spin the model a few times to get the frame rate moving. I'll check the code later.

PS I really feel that would be very useful to have a preference option to choose if loading STEP files as before or in A3 new mode.

Yes, I'll add back the original code, for easy comparison, too.

[easyw-fc]

then I'd say the upstream importer is wrong. For example,
For both https://www.cax-if.org/library/as1-oc-214.zip and https://www.cax-if.org/library/as1-tu-203.zip, the upstream importer gives name as

here what I get from DSM and this is exactly what the actual FC importer gives.

as-ac-dsm.png (32.56 KiB) Viewed 1984 times

Do you know the original hierarchy in SW? You can't really judge solely by the complexity of the hierarchy. Those unexpanded object are not expanded by my importer because they are saved as compound with no child object naming information. The upstream import does expand the compound but flatten to only one hierarchy, and it only extracts solid and shell, while discarding all the others, which is why you have problem with edge in your other file. You can check inside the hierarchy to confirm that all children names are auto generated. The actual hierarchy in the compound can be much more complex.

I cannot have a SolidWorks comparison, may be someone at the forum may help in this, but what I get from DSM is exactly what we get from the actual FC importer.

dsm-ur10.png (44.24 KiB) Viewed 1984 times

The loading time is off. I have repeatedly tested on my computer, and it always takes about 190 with my importer, and 310 with the upstream. Have you considered the file cache effect? There are really two stages of importing. One big part is the file reading, i.e. the one with the progress bar, which are solely handled by OCCT. The other stage makes FC appears to be frozen. And that is the actually processing time of the importer.

I'm using the python script that I posted few posts ago to calculate the loading time... I don't care about caching or whatever, I get the time from the beginning of the loading process and when the model is usable by the user.

The frame rate is also off. I do notice that the frame rate reported is not always accurate. In my computer it is the upstream sometimes stuck at 2fps, and I'll have to manually spin the model a few times to get the frame rate moving. I'll check the code later.

The same for frame rates, I can see a real difference in handling of the models when I turn them manually, so I would say that fps counting may not be accurate, but it displays correctly a quite different behavior between actual implementation and the A3 one.

Yes, I'll add back the original code, for easy comparison, too.

That's fine, thank you.

As I already pointed out before, STEP implementation is about CAD interoperability, then what is important is to check what you get or what you generate when importing and exporting files generated not only by FC, but particularly by other proprietary sw.
You may consider to compare your results with DSM and VariCAD... they are both available for free and they both use a different CAD kernel and STEP parser library. We did this checking during the tuning process and moreover Jean Marie checked the results also on SolidWorks and PTCreo.

Maurice

[realthunder]

167]
here what I get from DSM and this exactly what the actual FC importer gives.

So, you are saying it is okay to not use the instance names even if they are given? It is certainly okay to use the base name when the instance names are not available, and I am going to modify my code to do just that.

I cannot have a SolidWorks comparison, may be someone at the forum may help in this, but what I get from DSM is exactly what we get from the actual FC importer.

I feel like you are kind of biased, because this screenshot together with the one above actually shows that the upstream imports the hierarchy wrongly. Do you notice the different icons DSM used? It is not that hard to guess which icon is for group, which is for object. I'll say that the green icon has no equivalence in FC. Those green icon with a lock is showing the internal subshapes. I guess the lock means it's internal and not changeable. Notice that the 'plate' in your first picture can also be expanded to reveal a green icon child.

I'm using the python script that I posted few posts ago to calculate the loading time... I don't care about caching or whatever, I get the time from the beginning of the loading process and when the model is usable by the user.

The file cache is service provided by the OS. It means opening and reading a big file the first time will be slower than reading it again. Did you use my branch to open the big file first?


Here is the thing. You are testing things as black box, which is by all means necessary, but it has disadvantage if it is used as the only way. You seems to think that I take the STEP stuff too casually. On the contrary, I fully appreciate its complexity. In order to implement it, I read Jean's code, the STEP recommendations, the OCCT code, and was able to identify some of their bugs and found workarounds. This is how I know the label problem, and compound expansion problem. I did a lot white box test, and I can easily construct some STEP that shows some problem I found in Jean's code.

I originally wanted to just modify Jean's code to add the Link stuff, but found that the required modification is practically a rewrite. Did you see the picture I posted earlier, about AS1 assembly structure presented in STEP recommendation? The hierarchy is not a tree like what Jean's code outputs, but a graph, and graph is much more complex to handle.

[saso]

Tell me when you (not anyone specifically, more like the community) will be ready to accept what I have been arguing about for the past six months so we can finally, fix things and make them as they should be.

[easyw-fc]

So, you are saying it is okay to not use the instance names even if they are given?

No, I'm saying you have to test your importing and exporting results in proprietary CADs to know if you are doing a good job for what STEP is meaningful.

I feel like you are kind of biased

No, I'm not .. What should it be my vantage? ... I'm just trying to keep the STEP Importer/Exporter as its best. I didn't get any complaint in more than a year since Jean Marie refactoring. And I'm quite present both here and at KiCAD forum, where many users are using FC to export their boards to commercial CADs.

because this screenshot together with the one above actually shows that the upstream imports the hierarchy wrongly. Do you notice the different icons DSM used? It is not that hard to guess which icon is for group, which is for object.

In fact there are Part group in Part group in FC importer
the up Part container 'Universal_Robots___UR10' is the 'UR10' DSM main container, the FC 'Size_4_Joint' inside container is the DSM 'Size 4 Joint' container and then there are the internal shapes.
in A3 everything is flattened and the Labels are not related to what DSM is displaying.

step-comparison-2.PNG (175.65 KiB) Viewed 1940 times

I'll say that the green icon has no equivalence in FC.

the green icon is a Shape as in FC the blue icon

Those green icon with a lock is showing the internal subshapes. I guess the lock means it's internal and not changeable.

Those are locked because DSM doesn't allow to modify a STEP imported file.
I attached above a new screenshot in which I removed the lock by allowing an editing.

Notice that the 'plate' in your first picture can also be expanded to reveal a green icon child.

If you mean the 'Upper arm' then in FC the importer is missing the inside Part container.

The file cache is service provided by the OS. It means opening and reading a big file the first time will be slower than reading it again. Did you use my branch to open the big file first?

I normally do my tests closing all FC instances (main branch or A3 branch) and do the loading/comparison, so I don't think this can be involved.

Here is the thing. You are testing things as black box, which is by all means necessary, but it has disadvantage if it is used as the only way. You seems to think that I take the STEP stuff too casually.

No, I'm sorry if you think so, but at the same time you must consider that what is the meaning of a STEP file is interoperability... if you code your importer exporter without make any comparison with the commercial sw, then you will miss the real target of the job.
The testing as black box is exactly what is needed for the wanted result.

I originally wanted to just modify Jean's code to add the Link stuff, but found that the required modification is practically a rewrite. Did you see the picture I posted earlier, about AS1 assembly structure presented in STEP recommendation? The hierarchy is not a tree like what Jean's code outputs, but a graph, and graph is much more complex to handle.

you are most welcome if you want to improve what we have ATM, but you cannot avoid to compare your results with what commercial CADs are doing, unless you want to force other CAD's vendors to change their parsers.
Have you access to at least some commercial CAD?

And just to close this long post, I had warned you that STEP importing/exporting would not have been a simple task, so I consider that it will delay A3 merging as I already pointed out above.

[saso]

Sorry but you are both wrong...

In fact there are Part group in Part group in FC importer

Yes and this is crazy.

And about Asm3, I am sorry but IMO this is not the Assembly WB that the FreeCAD project is waiting for. Personally I wound not even call this an assembly. This is an implementations of 3D constraints between the geometry objects. Assembly is a structure of Parts and Assembly (in some programs also called Products) containers. I am not saying all this is useless, on contrary it is mostly great but it is not what the Assembly that we are waiting for should be...

If I try to explain it with a different example, lets say we would not have the Sketcher as we have it now in FC, but we would have the Draft WB. Just adding constraints between the Draft geometry would not give us the Sketcher. It can work similar and be useful for some cases but it would not be the Sketcher. IMO Asm3 should be split in two, one implementation that works on top of the Part, Assembly (Product) container structure, this would be the Assembly WB and a second implementations that can be sort of like Asm3 is working now but will be used just between the geometry objects inside of Parts or in workflows where users will not use the Part, Assembly structure for their models (this is actually how FreeCAD was and still mostly is working now since the Part and Assembly structure is not properly implemented yet).

[easyw-fc]

Sorry but you are both wrong...

may be you are right or may be not... I saw your discussion in the forum and not all agree on your point of view...

In fact there are Part group in Part group in FC importer

Yes and this is crazy.

If you have a top Assembly container and then you want to include this into an assembly as a sub-assembly, then I don't see any difference in top Container and the inside Container... So I consider Part as the right candidate.
This is exactly what you get when you assembly STEP objects.

[saso]

I saw your discussion in the forum and not all agree on your point of view...

Would love to hear and discuss them

In fact there are Part group in Part group in FC importer

Yes and this is crazy.

If you have a top Assembly container and then you want to include this into an assembly as a sub-assembly, then I don't see any difference in top Container and the inside Container... So I consider Part as the right candidate.
This is exactly what you get when you assembly STEP objects.

Show me one program that is using single container for both Assembly and Parts. Inside of an Assembly container you generally put only other assemblies (as sub assemblies) and Parts. Inside the Part container you put basically everything else (geometry, datum objects,...).

[easyw-fc]

Show me one program that is using single container for both Assembly and Parts. Inside of an Assembly container you generally put only other assemblies (as sub assemblies) and Parts. Inside the Part container you put basically everything (geometry, datum objects,...).

I only say that Part can do the right Job. If you want to create a new Container that is fitting your vision, you are allowed and welcomed. ATM what @ickby has done with Part container is doing a great job, particularly for what is needed in STEP assemblies.

I saw your discussion in the forum and not all agree on your point of view...

Would love to hear and discuss them

If you don't gather attention there,
https://forum.freecadweb.org/viewtopic.php?f=8&t=26357
please don't move the subject here.

[saso]

Show me one program that is using single container for both Assembly and Parts. Inside of an Assembly container you generally put only other assemblies (as sub assemblies) and Parts. Inside the Part container you put basically everything (geometry, datum objects,...).

I only say that Part can do the right Job. If you want to create a new Container that is fitting your vision, you are allowed and welcomed. ATM what @ickby has done with Part container is doing a great job, particularly for what is needed in STEP assemblies.

Ickby has build the implementation on top of this https://github.com/FreeCAD/FreeCAD/tree ... sembly/App you can see that both Part and Product (Assembly) containers are present there. This is how the proper full implementation of it in FreeCAD would look, note the Assembly (Product) container icon...

Untitled.png (40 KiB) Viewed 1885 times

And on the other side, this shows IMO one of the important misunderstandings that I often see in different posts in this forum, geometry is not a Part, Part is a container... And it is why I argue above that Asm3 is not an implementation of the proper Assembler WB but an implementation of 3d constraints between geometry.

Untitled1.png (17.84 KiB) Viewed 1873 times