Links

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Links

Post by realthunder »

triplus wrote:P.S. When i try to run DOF animation:

Code: Select all

AttributeError: 'App.Link' object has no attribute 'Shape'
How did you create the link? There are two types of links existing at the moment. App::Link does not have Shape, but Part::Link does. You can either use Part WB icon, or PartDesign icon as shown below. When using PartDesign icon, you need to select the Part::Feature derived shape you want to link first before click the icon to create the link, otherwise it creates an empty App::Link. Part::Link has a green arrow instead of white one as App::Link. The reason for two different type of links is because shape linking is still in early stage. I am not sure how well it works, and haven't really tested it. But in the future, we may be able to merge these two.
Screenshot from 2017-05-14 11-11-27.png
Screenshot from 2017-05-14 11-11-27.png (16.03 KiB) Viewed 2676 times
Screenshot from 2017-05-14 12-52-24.png
Screenshot from 2017-05-14 12-52-24.png (15 KiB) Viewed 2676 times
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Links

Post by triplus »

When using a Part Link Assembly 2 DOF animation works as expected. Therefore Shape attribute isn't missing. I noticed Part Link can't be used directly on PartDesign Box. I had to insert Part Box instead. Links have properties exposed but i noticed they just change the base object and all links adapt accordingly. Is this optimal behavior? Or would removing properties make more sense? Or to be able to set property like color for the individual Link? And as said i don't feel all that comfortable calling them links. We always called such geometry (Draft) Clones in the past.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Links

Post by realthunder »

triplus wrote:Links have properties exposed but i noticed they just change the base object and all links adapt accordingly. Is this optimal behavior? Or would removing properties make more sense? Or to be able to set property like color for the individual Link? And as said i don't feel all that comfortable calling them links. We always called such geometry (Draft) Clones in the past.
Links don't actually have those properties. I tweaked PropertyView to show the base object properties when one of its link is selected. And that's precisely the reason why it is not called "Clone", because link doesn't actually provide true separate identity. All properties are "linked", except visibility and placement. It is difficult to have cloned properties and still keep the efficiency of 3D representation sharing. It may be possible by using Coin override property node, but I haven't explore on that yet. You'd better use the draft clone if you really want things like independent materials, transparency, etc.

That being said, I am working on a new type of link called LinkSub, which is analogous to PropertyLinkSub that can link to sub elements or objects inside arbitrarily nested geo groups. It has limited capability to permanently highlight the linked subelement with a color of choice, meaning that it can recolor part of the shape. It can't actually show only the linked subelement (face, edge, etc), yet, but instead the entire shape with highlighted subelement. This limitation is due to the intricacy of 3D picking. So its usefulness is limited at the moment. I imagine that it could be a perfect replacement for assembly2 constraints linking if it works.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Links

Post by triplus »

realthunder wrote:And that's precisely the reason why it is not called "Clone", because link doesn't actually provide true separate identity. All properties are "linked", except visibility and placement. It is difficult to have cloned properties and still keep the efficiency of 3D representation sharing. It may be possible by using Coin override property node, but I haven't explore on that yet. You'd better use the draft clone if you really want things like independent materials, transparency, etc.
Therefore i am guessing it's safe to assume this won't ever be tackled in a way such property will work beyond changing base object? Having such property only for base object therefore makes more sense or not?

As for terminology i don't know. Dilemma i have is we are talking about the produced geometry (user point of view) and therefore the term link to me is more like a "connection" between base and produced geometry and not the produced geometry itself. From programmer/code point of view maybe it looks more like a link but from user point of view geometry is the outcome. That is just my observation and beyond stating that i don't really care.
That being said, I am working on a new type of link called LinkSub, which is analogous to PropertyLinkSub that can link to sub elements or objects inside arbitrarily nested geo groups. It has limited capability to permanently highlight the linked subelement with a color of choice, meaning that it can recolor part of the shape. It can't actually show only the linked subelement (face, edge, etc), yet, but instead the entire shape with highlighted subelement. This limitation is due to the intricacy of 3D picking. So its usefulness is limited at the moment. I imagine that it could be a perfect replacement for assembly2 constraints linking if it works.
With links you therefore can create a Link if you want more light weight geometry representation of the base geometry. Or you can use Draft Clone if you want the full geometry with all its properties. After you can add relation with Assembly 2 between a Link and a Draft Clone.

As for the LinkSub. If i understand you correctly one use case would be to visually differentiate geometry used in for example assembly relation? Used on Links or any geometry or ... ?
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Links

Post by realthunder »

triplus wrote:Therefore i am guessing it's safe to assume this won't ever be tackled in a way such property will work beyond changing base object? Having such property only for base object therefore makes more sense or not?
I think I'll add whole object material properties (shape color, transparency, etc) if it is not too much trouble. It will be very useful to visually differentiate between all the link instances.
triplus wrote:As for the LinkSub. If i understand you correctly one use case would be to visually differentiate geometry used in for example assembly relation? Used on Links or any geometry or ... ?
Visual differentiation is not the primary purpose, but yes, for linking that keeps the assembly relation information. I added LinkSub to address one fundamental limitation of the current Link, which is, iconically, created by Link itself.

Before App::Link, objects can only meaningfully belong to one immediate geo group. So, given an object by itself, we can determine its placement by going through all its immediate and ancestor geo groups. But now, a linked group can have independent placement. So, there is no way to tell the placement of the object without the list of all its ancestor (linked) groups. I'll call this list of (linked) group names leading to the object as the full qualified name of the object. To be compatible with existing FC selection API, when you select an object, the full qualified name is shown as the SubName, just like a Face or Edge to a TopoShape. Current Link has no way to link to full qualified name. Linking to an object creates a new "placement identify", and the full qualified name information in selection is lost. FC has PropertyLinkSub to store the object link and a subelement list. And LinkSub uses this property to link to full qualified named sub object(s).

To an end user point of view, with Link, you can independently move the original object and its link. Use LinkSub if you actually want the placement to be linked as well. Original App::Link has a property called 'LinkTransform' which can link the placement of the original object. But it won't work for objects inside (nested) geo group(s), which is exactly what LinkSub is for.

A bonus effect for LinkSub is that it can easily be used to represent a partial (or full) App::Part, with overridden visibility of its children. Meaning that toggling children object visibility won't effect LinkSub's appearance. With that, Part::LinkSub can be used to create a linked compound shape, so that you can do geometry modeling with App::Part as well.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Links

Post by triplus »

realthunder wrote:I think I'll add whole object material properties (shape color, transparency, etc) if it is not too much trouble. It will be very useful to visually differentiate between all the link instances.
If that isn't feasible we will need to make some distinction that makes sense. Something like a Clone (Draft Clone) and a Shallow Clone (Link). As i do imagine if Draft Clone would make use of Links in the future there would be a checkbox to switch between both "low fat" and "full" version of Cloned geometry. Or do you imagine Links could provide drop-in full replacement for Draft Clone in the future?
To an end user point of view, with Link, you can independently move the original object and its link. Use LinkSub if you actually want the placement to be linked as well.
Therefore LinkSub is another type of (shallow) Clone? The difference (compared to Link) being it doesn't have the placement properties as that is controlled by base object?
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Links

Post by realthunder »

triplus wrote:If that isn't feasible we will need to make some distinction that makes sense. Something like a Clone (Draft Clone) and a Shallow Clone (Link). As i do imagine if Draft Clone would make use of Links in the future there would be a checkbox to switch between both "low fat" and "full" version of Cloned geometry. Or do you imagine Links could provide drop-in full replacement for Draft Clone in the future?
Therefore LinkSub is another type of (shallow) Clone? The difference (compared to Link) being it doesn't have the placement properties as that is controlled by base object?
It is going to be very hard to design a feature that fits so many potential use cases. For example, the LinkSub here. It makes sense to not having its own placement in some cases, but there are always exceptions. And this why I am exposing the core functionality of Link into a python object. It is not a Feature, nor ViewObject, but a lightweight python object without any properties of its own. It is mainly designed to be a helper for writing customized feature and view object requires link functionality. A perfect demo I have in mind is to use this to write an array feature, reusing most of Draft Array's python code for generating patterned placement, but replacing the View Object with the help of Link. So, in that sense, yes, maybe Draft Clone can be enhanced this way, too, as an option.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Links

Post by triplus »

I see. Well therefore ATM i feel like Link (shallow Clone) is what i plan to use if it makes it into master. As for LinkSub i will wait and see but i do imagine i could just use the geometry directly when using the Assembly 2 to add relations.

P.S. And one additional question. Have you any ideas on how you could make Link work efficiently in a way for the base geometry to be provided in a separate document?
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Links

Post by realthunder »

triplus wrote:P.S. And one additional question. Have you any ideas on how you could make Link work efficiently in a way for the base geometry to be provided in a separate document?
Have you tried my demo file in the very first post of this thread. The cross document linking is already working, but need more testing of course. The PropertyLink inside App::Link is actually PropertyXLink that I created for exactly this purpose. In fact, I wrote Link with assembly2 use cases in mind. The Link property can be edited in property view. Once the editor pops up, there is a combo box at top that you can select which document to browse the objects. PropertyXLink requires that both the owner document and referencing document be saved at least once before assigning the link, because it needs to know the file path of the two documents in order to calculate the relative path for storage. When you opens a document containing PropertyXLink, FC will automatically opens the referenced document as well. When you close the referenced document, the linked object is lost, but will be regained once you open the referenced document again. So you can safely swap a file with objects of the same names, and the links remain valid. However, I imagine you do need some special logic to deal with this lost and regain scenario efficiently when using Link for assembly constraints and stuff, for example, to avoid excessive constraints recomputation.

In the commits I have yet to push, the document tree can now display children items from other documents as well, for easy navigation and editing. It makes sense because those children items brought in by Link actually have 3D representation inside current 3D view. Any change of properties of the foreign items are immediately relected in the 3D view. With Link, document will no longer be a hard boundary for FC in the future.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Links

Post by triplus »

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).
Post Reply