Assembly3 preview

[alberich]

Anyway, thank you realthunder for your work on the Assembly 3 Workbench. You picked up the ball from where it was dropped or fumbled years ago and are heading for a touch down. You are awesome!

+1 on this.

Also, a question. For all of us cheering your progress down the field, where is the goal line? That is, what milestone is needed to be reached for A3 to be merged into the daily build?

[sgrogan]

https://github.com/FreeCAD/FreeCAD-ports-cache/releases/download/v0.18/FreeCADLibs_11.11_x64_VC12.7z

An update in your appveyor.yml will then use this. I need more testing for a pull request, but this is what I’m using for Win developer builds.

[realthunder]

Also, a question. For all of us cheering your progress down the field, where is the goal line? That is, what milestone is needed to be reached for A3 to be merged into the daily build?

A3 is developed as a test and demo to show that my core changes of FC works. And I think my branch is ready for merging now. There are of course lots of bugs expected, but the design of all the changes is to maintain backward compatibility first. I am not sure what the lead developers think about this, although I can understand that this is a huge changeset, approaching 50K lines of changes.

If my branch is merged, it doesn’t really matter if A3 is in the master or not. It can exist as an Add-on. And I personally think it will be better to have the assembly workbench written in C++, but that won’t happen until we can find a proper solver with compatible license, or write our own.

As for the road map of A3 itself, I have two big features in mind.

• Import assemblies built with A2. I personally need this, because I have huge assemblies built with A2 long time ago. I considered of doing the import since the beginning. But A3 was not matured enough to do this. I think it is ready now.

• DOF analyzer and animator. I studied SolverSpace’s code for this already, and I had a rough idea how it works. I may need to patch SolveSpace solver library a little bit in order to bring out this functionality.

[realthunder]

https://github.com/FreeCAD/FreeCAD-ports-cache/releases/download/v0.18/FreeCADLibs_11.11_x64_VC12.7z

An update in your appveyor.yml will then use this. I need more testing for a pull request, but this is what I’m using for Win developer builds.

Thanks, I’ll use it in my next release

[realthunder]

Here a full designed vise I drew.

Which version of FC you used to make this? It didn’t store transient properties correctly. I remember one of my releases has this problem. Are you using one of my release to make this?

BTW I had an issue with @GlouGlou file if opened in A3 build… I had to open it in FC0.18 and then save it.

You can open this file in 0.18? Exactly which version and platform are you using? I tested 0.18 on Linux and it crashes, due to the transient property problem I mentioned above.

Edit, ah right, you saved it once in my branch, by which you fixed the transient property problem, and the resulting file can be opened in 0.18. You can ignore the error message. I’ll get rid of it in the next release.

[triplus]

• Import assemblies built with A2.

Any chance you would be prepared to maintain a fork of Assembly 2 for the purpose of Qt5 (and potentially Py3) porting?

[easyw-fc]

Edit, ah right, you saved it once in my branch, by which you fixed the transient property problem, and the resulting file can be opened in 0.18.

there must be something wrong with this document… If I make a recompute, FC just hangs and then crash…

App.ActiveDocument.recompute()

(the same in FC0.18 after marking the document for a recompute)

[realthunder]

Any chance you would be prepared to maintain a fork of Assembly 2 for the purpose of Qt5 (and potentially Py3) porting?

I’m not sure if I’m up to the task. A2 code is not really documented, and hard to understand. I originally wanted my A3 as a fork of A2, but gave up in the middle of porting. I’m not that good at Python comparing to C++.

[easyw-fc]

@triplus

As for Link effort. The way i see it one thing is still missing. In use cases where you create a Link to geometry in external file. And there is substantial amount of “design history” in that file. Or in use cases where you need to have a big number of “part documents”. There should be a way (one example of a solution to the problem being Assembly 2 import feature). Where only the “subset of geometry” would get loaded and documents wouldn’t need to be opened at all. Or it would be opened only to extract a “subset of geometry” to crate a Link feature and after to be closed.

That’s a nice feature to have. I’ll think about it.

@realthunder
Is there anything similar to what A2 is doing, like loading the shape of an external document into A3, through Links or similar?

I think that would lighten A3 job and the final document for the assembly, particularly when you need to assembly many parts together… Just update the source document and update the links to get the Assembly up to date…

[realthunder]

@realthunder
Is there anything similar to what A2 is doing, like loading the shape of an external document into A3, through Links or similar?

I think that would lighten A3 job and the final document for the assembly, particularly when you need to assembly many parts together… Just update the source document and update the links to get the Assembly up to date…

I haven’t figure out how to do that yet. Because A3 is so deep into this hierarchical thing, it’s not easy to achieve similar effect as A2. But I’ll definitely work on that in the future.

[easyw-fc]

Any chance you would be prepared to maintain a fork of Assembly 2 for the purpose of Qt5 (and potentially Py3) porting?

If we can get an A2 fork managed by FC folks, we could easy gather some user aimed to do the fix…
And then focus the efforts on A3

[triplus]

I’m not sure if I’m up to the task. A2 code is not really documented, and hard to understand. I originally wanted my A3 as a fork of A2, but gave up in the middle of porting. I’m not that good at Python comparing to C++.

Fair enough.

If we can get an A2 fork managed by FC folks, we could easy gather some user aimed to do the fix…
And then focus the efforts on A3

I know there is demand as threads like this emerge:

https://forum.freecadweb.org/viewtopic.php?f=20&t=28628

There is still development activity involved:

https://forum.freecadweb.org/viewtopic.php?f=22&t=26797&p=218959#p218959

What is therefore likely missing is somebody managing the pull requests. I tried to came up with a solution that makes some sense. As it didn’t happen that is it from my side for now. Will let things evolve naturally. On macOS therefore FreeCAD 0.16 should be used to create assemblies with Assembly 2 for now.

[realthunder]

Can someone please try this attached file, and try to make a draft with the following selected face. I am not familiar with PartDesignNext. I can’t seem to select a neutral plane that works.

The draft angle is 5 degree, and should look like this

I notice that PartDesign FeatureDraft can guess a neutral plane and pull direction just fine. But the Gui TaskDraftParameters insists on an explicit neutral plane selection. What’s more strange is that FeatureDraft is able to derived the neutral plane using the following Edge1? How can it be?

@GlouGlou

ping

This is extracted from your model. How did you manage to get the draft in the first place?
pdn-draft-test.fcstd (64.6 KB)

[Jee-Bee]

this?
pdn-draft-test-answ.FCStd (55.7 KB)

[Vincent_B]

The neutral plane can be like this.
The pull direction is an edge perpendicular of the plan.
Invert the direction as required.

DratfGG.FCStd (55.8 KB)

[realthunder]

I am currently working on STEP import/export for better assembly usage. And found this interesting document (Edit: just found the latest version of the document). I was searching for some obscure abbreviation found in OCCT data exchange code, and this document perfectly explained what is missing in OCCT documentation.

Specifically, what I found interesting is this,

Right now, NAUO (Next Assembly Usage Occurrence) can be directly translated to Link. But SHUO (Specific Higher Usage Occurrence) is missing, which is used to override visibility and color of an instance under a specific context. In the above picture, it means change the color of the third instance of Nut-Bot-Assembly in the second instance of L-Bracket-Assembly in the top assembly, AS1.

I think I can extend my Coin3D trick on context-aware selection, and applied it to color and visibility to achieve this.

[easyw-fc]

I am currently working on STEP import/export for better assembly usage. And found this interesting document. I was searching for some obscure abbreviation found in OCCT data exchange code, and this document perfectly explained what is missing in OCCT documentation.

Specifically, what I found interesting is this,

Screenshot from 2018-05-14 15-21-10.png

Right now, NAUO (Next Assembly Usage Occurrence) can be directly translated to Link. But SHUO (Specific Higher Usage Occurrence) is missing, which is used to override visibility and color of an instance under a specific context. In the above picture, it means change the color of the third instance of Nut-Bot-Assembly in the second instance of L-Bracket-Assembly in the top assembly, AS1.

I think I can extend my Coin3D trick on context-aware selection, and applied it to color and visibility to achieve this.

Hi @realthunder,
if you want to make some test here you can find some STEP files generated from different SW and with or without hierarchy.
https://www.cax-if.org/library/index.html

here a test file with hierarchy:
https://www.cax-if.org/library/as1-oc-214.zip
https://www.cax-if.org/library/as1-pe-203.zip
https://www.cax-if.org/library/as1-tu-203.zip

and here a file with external references (similar to what it could be done with your ‘Links’ pointing to external files)
https://www.cax-if.org/library/s1-c5-214.zip
https://www.cax-if.org/library/s1-pe-214.zip
https://www.cax-if.org/library/s1-tu-203.zip

Hierarchy is already well supported by FreeCAD ATM.
External references are supported only when importing the file, but are not implemented when exporting.
https://www.cax-if.org/documents/rec_prac_ext_ref_v21.pdf
Links could really make the difference here
Maurice

[realthunder]

Hi @realthunder,
if you want to make some test here you can find some STEP files generated from different SW and with or without hierarchy.

Thanks, much appreciated!

[freedman]

I just tried assembly3, it looks good but I couldn’t select any faces so I really couldn’t test much. What is the status of this?

OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.13844 (Git)
Build type: Release
Branch: (HEAD detached at FETCH_HEAD)
Hash: 53a08259946dfa0f02bdd02a7746667902e42728
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
Locale: English/UnitedStates (en_US)

[realthunder]

I just tried assembly3, it looks good but I couldn’t select any faces so I really couldn’t test much. What is the status of this?

Can you please elaborate your problem? Can you select a face when create, say a Cube, using Part, PartDesign? Does the problem happen only when the object is in the assembly? If you can show show screencast, that will be better.