this is a fork of another thread on this forum (Relevance of "Feature is not in a part" error message) because some very important points have been raised, and I would like to add my 2 cents. I hope I'm not too late to the party. Here are some relevant quotes:
First, I think it's very important to have 2 different containers, in a hierarchical level, one for bodies and one for parts. IMHO the FreeCAD developers have done it mostly right. The names might not be well chosen — easy confusion between Part and PartDesign — but the principle holds. A physical part can hold different bodies, either because the single part is made of different materials — look at your toothbrush — or because it's made with booleans, meaning that temporarily there are several bodies. So the higher level container will contain all those lower level containers, which in turn will contain atomic functions. Historically, calling them "Part" and "Body" seems like a good choice. If PartDesign was renamed BodyDesign, for example, it would lift some of the confusion.
But the most important part comes from the assemblies.
I have played with realthunder's App::Link implementation, and we managed to come up with a working solution for assemblies. I think it's a very practical and elegant solution, but it's not 100% what people imagine how assemblies should work in a traditional CAD system. You can see results here and here. It's very manual at the moment, a proper GUI would be necessary. This is not realthunder's Assembly3 workbench, it doesn't use it at all, but it uses realthunder's App::Link stuff. From what I understood, the Assembly3 is a demonstrator on top of App::Link. I think that merging the App::Link, with or without Asm3, should be a priority for v0.19
With trial-and-error, I think we have come a long way and can propose a well working assembly architecture. What I propose is that the App::Part be indeed the assembly container, that can contain either directly a PartDesign::Body, or several ones, to form a physical part, or App::Link links to other App::Parts and then it's an assembly. Can also hold Datum objects, Sketches, ... This is quite exactly how Siemens NX works, and quite unlike Catia V5. FreeCAD would be in the top-of-the best league. Additionally, each App::Part should contain a "Constraints" group to store constraints if it is used as assembly. Here is how the hierarchy would look like:
Code: Select all
Model (App::Part) = Part or Assembly │ ├─ Constraints (App::DocumentObjectGroup) │ ├─ PLM_Model2 (App::Placement) │ ┊ │ ├─ LCS_0 ┐ ├─ DatumPlane │ ├─ Sketch │ ├─ LCS_1 ├ references ├─ DatumAxis │ ├─ LCS_2 │ ├─ ... ┘ │ ├─ Body (App::PartDesign) = geometries │ ├─ Solid_1 │ ├─ Solid_2 │ ┊ │ ├─ Model2 (App::Link) = another App::Part │ │ │ ├─ Constraints │ ┊ │ ├─ LCS_0 ┊ ┊
And here in FreeCAD.
Files are attached for testing. They include my macros (they're only 1-liners mostly). I've put those macros in the toolbar to automate the process. This only works with realthunder's LinkStage3, there is a freshly released AppImage. All comments are welcome.