Links

[realthunder]

All documents involved in providing the geometry for "assembly file" will therefore always need to be open? Contrary to current Assembly 2 approach where you basically can delete all external documents and "assembly file" should still load successfully.

I don't know to be honest what is better. Likely it depends on the use case and each approach has its pros and cons (relevant to use case).

We can have a button in the future assembly WB to 'import' all or selected external linked object into the same document, and maybe a button to do the export also. We can already copy and paste objects between documents. This should be easy to automate.

[triplus]

I don't know to be honest. My current preference likely is to always import (simplified version) of base geometry. As Assembly 2 does. And make heavy use of Links whenever possible (but only when it makes sense). Therefore lets say you have one base geometry and 10 links in referenced document. I wouldn't go down the road to have 11 Links in "assembly document". I would rather see simplified version of base geometry to be imported and 10 links to be made after. As this way you don't introduce any real limitations and you preserve the integrity of "assembly document". Basically use Links for what they are good for and don't try to make everything Links (if something works better). For example Assembly effort only needed 1 (type of) container (to put things in it and move them around). And look at the result. Now we want to make everything a special container regardless of the fact if it makes much sense or not.

P.S. But note that this is just my current opinion. We had the same discussion years back where there was nothing yet developed. And (most strangely) opinions differed severely.

[realthunder]

P.S. But note that this is just my opinion and we had the same discussion years back where there was nothing yet developed and opinions differed severely. And it could be some other approach that differs from what i wrote works better.

Well, I have this device completely modeled using FC with more than a hundred individual parts, some of which are very complex, and I am not counting fasteners. Try to put that into one assembly file, and trying to do any update. That's pain! Besides, for large scale projects, you'll need version control. Putting all objects inside one assembly is going to be a mess.

On the other hand, if the assembly is structured properly, it shouldn't care whether the geometry is external or not. Like the example you mentioned, I'd always create 11 links. The extra links is for linking to the actual geometry, and be hidden in 3D view. The other 10 links link to that extra link. This way, I can always change this extra link later to pointing internal or external. The other 10 links and their placements remain the same. The whole assembly becomes abstract.

[triplus]

I wouldn't say abstract as we likely could expose abstract references to be used for assembly purposes (links or base geometry). For example center of mass as a point. That is abstract reference. As adding relations to such references will always work predictably. No topology implications involved. Obviously useful in some use cases but not a silver bullet for everything. Link on the other hand is still geometry and its for example face still isn't abstract but it is tied to base geometry (changing) topology. Just like base geometry.

As for 10 + 1 or 11 example. I realized 10 links would likely be some sort of an array. Therefore external Array feature would be used in "assembly document". In such use case FreeCAD would need to take the array and determine it consist of links, find its base feature and use that instead in "assembly document" and know what to do with links. That sounds like sci-fi!

Anyway as for Links they make perfect sense to me for re-usage of geometry. As for only using links in "assembly document" or not. Lets see what the future brings. Solutions that preserve integrity of files (Assembly 2) is something i in general prefer. That is why i said i would like to see combination of Links and "simple geometry". But i do acknowledge not all feel the same.

[realthunder]

I wouldn't say abstract as we likely could expose abstract references to be used for assembly purposes (links or base geometry). For example center of mass as a point. That is abstract reference. As adding relations to such references will always work predictably. No topology implications involved. Obviously useful in some use cases but not a silver bullet for everything. Link on the other hand is still geometry and its for example face still isn't abstract but it is tied to base geometry (changing) topology. Just like base geometry.

About that, remember our conversation in the other thread about this? With Link, it is now possible to NOT tie the constraint to the actual part geometry, which is potentially volatile. Inside a container, you can have simple geometries, faces, sketches, whatever, that are stable and hidden, that are used as constraint through LinkSub. Like my example in the other thread, a very detailed part with threaded socket using PartDesign comes from simple cylinder, which comes from simple circular sketch. How abstract the constraint can be is now up to the author of the Part. He can even have additional link inside the part container/file to abstract the actual constraint geometry, which essentially gives the volatile topological names a permanent name tag. The author can now freely change the model geometry inside the part without affecting the assembly.

As for 10 + 1 or 11 example. I realized 10 links would likely be some sort of an array. Therefore external Array feature would be used in "assembly document". In such use case FreeCAD would need to take the array and determine it consist of links, find its base feature and use that instead in "assembly document" and know what to do with links. That sounds like sci-fi!

Array is not always an answer. Think about fasteners or gears, they are duplicates in shapes, but has no pattern in placement. They have to be individual links. And those links are better pointing to a secondary "type" link, so that you can efficiently change the "type" later on.

Anyway as for Links they make perfect sense to me for re-usage of geometry. As for only using links in "assembly document" or not. Lets see what the future brings. Solutions that preserve integrity of files (Assembly 2) is something i in general prefer. That is why i said i would like to see combination of Links and "simple geometry". But i do acknowledge not all feel the same.

Yes, we shouldn't force user to use only linked geometry for assembly. That's for sure. Assembly's implementation can certainly take full advantage of Link. I'd imagine that the new assembly will have an extended geo group type container with the additional constraints object powerd by Link/LinkSub. The container can accept normal geometry object, normal geo group, linked object, and sub assembly container. But with such substantial changes, I highly doubt that we can maintain backward compatibility with assebmly2. Maybe an import function to convert from the old assembly.

[triplus]

With Link, it is now possible to NOT tie the constraint to the actual part geometry

And where does the Link get the geometry from? Doesn't the Link geometry update accordingly? Therefore for example doesn't Link face number change if base geometry face number changes? If base geometry will get all that hash history related topology information in the future. Links will highly likely reuse it? But that is the future and lets first see how things will progress in that area (for the base geometry).

I highly doubt that we can maintain backward compatibility with assebmly2.

I guess Assembly 2 for FreeCAD 0.16 and Assembly 2 for FreeCAD 0.17+ could work for me. Hopefully somebody invests the effort to make it happen.

Anyway you seem like somebody that is prepared to listen to feedback and acknowledge it. In addition to what was already discussed that is good enough for me for now. As for the rest good luck and looking forward to seeing progress being made.

[Jee-Bee]

I guess Assembly 2 for FreeCAD 0.16 and Assembly 2 for FreeCAD 0.17+ could work for me. Hopefully somebody invests the effort to make it happen.

@easyw-fc did it before maybe he is so nice to do it again

[realthunder]

Latest update:

* Link can now override the linked object's material, with UseMaterial and ShapeMaterial properties. Because the link doesn't know the detail coin tree structure of the linked object, it can only override the overall material. Face specific color list, line colors, etc. will be lost. It is mainly used as a convenience for distinguishing link instances.

* Link now has internal support for array. Unlike draft array, link's array elements can be freely moved and scaled, and have independent visibility and material override. You can either manipulate the elements using Python with PlacementList, ScaleList, VisibilityList and ViewObject.MaterialList proeprties, or set Link.ShowElement=True, and the elements will be shown as children object under the owner link. The element object is expandable in the tree view with the same children of the linked object. The 3D selection will nicely recursively sync to the nested child object in the tree view.

* Added Draft.LinkArray, and Draft.PathLinkArray, which are derived from Draft.Array, and Draft.PathArray. I have modified FC core to allow overriding view provider type of an existing document object using Python. Those link arries get their extra function by installing Part::LinkExtension to the Part::FeaturePython object, and switching its view provider to ViewProviderLinkPython. When ShowElement is False, Draft array's original property controls the element count, and the placements of those elements. When ShowElement is True, you can freely move those elements. Because of link, draft array now supports App::Part, although you'll need to set LinkShape=False to avoid warning, because link can't generate shape from App::Part, yet, due to the fact that the visibility state of its children is in Gui namespace, while shape composition is in App namespace.

* Added SubList property to support subelement linking. Say, you link to a cube object, and set SubList = [Face1,Face2]. The link will now only display those two faces. Another example, you can link to an App.Part object and show only some of its children, such as SubList=[Box, childPart.Box, childPart.grandChildPart.Box.Face1]

My Link branch has grown way beyond what a few PRs can handle. It needs a lot of tests to make it stable, and I think a working assembly based on link feature is the best way to attract more people to test it. So, here is a pre-announcement. I will start a fork of the assembly2 to take full advantage of the Link feature. Because of the amount of changes expected, I think I'll call it assembly3. Once, I got the basic features working, I'd be very much appreciated for anyone who are interested to contribute as well. I'll start working on this a bit later, though, maybe after a month, since I got caught up with something right now. When I started to work on assembly3, I'll try to keep the branch in sync with upstream master. I hope it will be a memorable milestone of FC when my branch is finally merged, some day!

[Jee-Bee]

why not just add it to Assembly 2?

[triplus]

Sounds good and lets see where does that take us. Before doing the actual PR i am guessing you should figure out the details. Maybe it should be split in parts. Currently GSoC project and PartDesign NEXT efforts are taking most of the developer related resources. But as this is interesting area i am sure you'll get some feedback when requested.