variant App::Link

[Zolko]

Hello,

this is a follow-up on one of my previous requests, and I'll try to describe here what I'd like to do. I think it should be possible to do it with current (pre-v0.19) FreeCAD, but I'm not sure.

Basically, what I'd like to do is (EDIT: I got the sequence wrong):

• load an App::Part from a file (or have it already opened)
• modify some parameters of that App::Part (like a length, an angle...)
• create a hidden temporary document
• deep-copy the (modified) App::Part into this new document
• modify some parameters of that App::Part (like a length, an angle...)
• link to that App::Part
• insert that link into an assembly
• the parameter can be changed from within the assembly, and when recalculating the assembly the (new) parameters shall be applied
• when closing and re-opening the assembly, the placement and parameters of the (variant) link shall be preserved/restored

The purpose is multiple, typical usage is:

• for a beam, have a single FreeCAD file with a default length, and be able to insert the beam several times into an assembly with different length
• a family of screw (yes, I know about the Fasteners WB) and set the parameters of the screw interactively in the assembly
• for a sub-assembly, have multiple versions of it in an assembly with different settings (like a switch that would have positions ON or OFF)
• ... I'm sure there are other use-cases

I didn't find a way to do this with stock App::Link, and I don't think it's possible. I think it's probably possible with an App::FeaturePython object, but may-be the App::LinkPython object is even better suited ?

This is just a Python extended version of App::Link, similar to what Part::FeaturePython to Part::Feature. Whether it is suitable for you or not depends on you need. Please elaborate, maybe in a separate post.

I did read the documentation about parametric objects and scripted objects but I don't understand them. Ideally, I'd like some very basic template object (App::FeaturePython or App::LinkPython) and I'd try to modify them to do what I want them to do.

This is what I did by hand that nearly works (I can't save the result to a file):

Code: Select all

asmDoc = App.ActiveDocument
tmpDoc = App.newDocument('tmpDoc', label='tmpDoc', hidden='True')
App.setActiveDocument(asmDoc.Name)
tmpDoc.FileName ='toto' 
beamCopy = tmpDoc.copyObject( asmDoc.getObject( 'Beam'), 'True' )
asmDoc.getObject('Beam_2').LinkedObject = beamCopy
asmDoc.getObject('Beam_3').LinkedObject = beamCopy
asmDoc.getObject('Beam_4').LinkedObject = beamCopy
copyVars = beamCopy.getObject('Variables')
copyVars.Length=50
copyVars.Size=50
asmDoc.recompute()

All help would be welcome.

[realthunder]

When link to a variant, do you need the hierarchy? Say, when you link to a variant sub-assembly, do you still need the children, or just a flattened compound shape.

[paullee]

Also something like generative facade / structure ?

Each instances of faces / structure element is variant - Blender can do something similar ?

Something heard supported by grasshopper, dynamo...?

Never done something like these though.

Screenshot from 2020-01-13_ r.jpeg (236.92 KiB) Viewed 5605 times

[Zolko]

When link to a variant, do you need the hierarchy? Say, when you link to a variant sub-assembly, do you still need the children, or just a flattened compound shape.

I have 2 use-cases in mind: one for variant parts where I don't care about hierarchy, and one for variant assemblies where I'd need to keep the hierarchy. So if this variant link could preserve hierarchy it would answer both use-cases.

Also something like generative facade / structure ? Each instances of faces / structure element is variant

Yes, something like that.

The typical use-case for variant assemblies I have in mind would be the following: imagine a building with many identical doors, each door having 3 positions: open, close, and in the middle. There would be 1 assembly for the door, with a variable indicating in which of the 3 positions the door is.

When inserting a variant assembly of the door, the parts forming the assembly are already in memory, so the variance is only about the positions of the parts in the assembly, but the parts are all identical. If I understand well how App::Link works, this would minimise memory usage, since all parts of all (variant) assemblies point to the same parts, therefore geometry is not duplicated. Which would not be the case of variant parts where you'd need to have a copy of the geometry for each variant in memory.

[realthunder]

I have 2 use-cases in mind: one for variant parts where I don't care about hierarchy, and one for variant assemblies where I'd need to keep the hierarchy. So if this variant link could preserve hierarchy it would answer both use-cases.

If you need the hierarchy, then you can't use temporary object. The copies have to be persistent. Without hierarchy, yes, you can do that behind the scene. It is difficult to achieve what you want with the current upstream. Besides, you'll need to write Python code to extend existing FC stock objects. That's what those two links you quoted are all about. FC stock object has certain extension point, so that when the object is restored or changed, your Python code will be called to handle those changes. But if you do it this way, the user will have to install your Assembly4 in order to use it. And as I read your post from the other thread, you try to avoid that. So my suggestion is to wait for my 'Configuration Table' PR, which provides solution to both of your use cases. This is not really a big PR, I think it has high chance to get accepted within 0.19 cycle. I'm currently merging my asm3 branch with the upstream. You can try the prebuilt image once it's ready.

When inserting a variant assembly of the door, the parts forming the assembly are already in memory, so the variance is only about the positions of the parts in the assembly, but the parts are all identical. If I understand well how App::Link works, this would minimise memory usage, since all parts of all (variant) assemblies point to the same parts, therefore geometry is not duplicated. Which would not be the case of variant parts where you'd need to have a copy of the geometry for each variant in memory.

By default, deep copy using Document.copyObject() will not include external objects. So if your door geometry lives in a separate document, then the variant Link (with my PR) will work exactly like you described.

[Zolko]

I have 2 use-cases in mind: one for variant parts where I don't care about hierarchy, and one for variant assemblies where I'd need to keep the hierarchy. So if this variant link could preserve hierarchy it would answer both use-cases.

my suggestion is to wait for my 'Configuration Table' PR, which provides solution to both of your use cases. This is not really a big PR, I think it has high chance to get accepted within 0.19 cycle.

I have seen your proposal for the configuration table, and that functuinality is quite exactly what I think is needed. However, I'm not able to judge the implementation details of that solution, and I'm not sure how urgent it is to have it merged for v0.19.

When inserting a variant assembly of the door, the parts forming the assembly are already in memory, so the variance is only about the positions of the parts in the assembly, but the parts are all identical. If I understand well how App::Link works, this would minimise memory usage

By default, deep copy using Document.copyObject() will not include external objects. So if your door geometry lives in a separate document, then the variant Link (with my PR) will work exactly like you described.

Excellent. I think therefore that I'll wait for that PR to continue on this variant link thingy (whether in v0.19 or in v0.20 we shall see).

[paullee]

Also something like generative facade / structure ? Each instances of faces / structure element is variant

Yes, something like that.

The typical use-case for variant assemblies I have in mind would be the following: imagine a building with many identical doors, each door having 3 positions: open, close, and in the middle. There would be 1 assembly for the door, with a variable indicating in which of the 3 positions the door is.

When inserting a variant assembly of the door, the parts forming the assembly are already in memory, so the variance is only about the positions of the parts in the assembly, but the parts are all identical. If I understand well how App::Link works, this would minimise memory usage, since all parts of all (variant) assemblies point to the same parts, therefore geometry is not duplicated. Which would not be the case of variant parts where you'd need to have a copy of the geometry for each variant in memory.

I read your beam_2, beam_3, beam_4 example in https://forum.freecadweb.org/viewtopic. ... 50#p343116.

As far a I can understand, this seem to be a copy rather than a Link? As for each instance, a different shape need to be generated. Realthunder's Link to my understanding just 're-use' the Shape, and in addition to Transform the placement, can Scale the Shape only.

In my thread, I use the Link with same Shape with door as an example there too, just the Door has a method() to position itself with variables / property in the object. Now Link are used to create instances, but this method() + these variables / property is not able to be 're-used' in the Link object - so for each Instances, I can't use the method() to position each instances. I then just Draft Clone that did the jobs - just now each Clone generate a Shape so the file get big etc.

Your example of door in different configuration seem much more difficult to achieve with Link... and Configuration Table seem generate different shape for each objects right?

Sorry I am confused myself

[Zolko]

I read your beam_2, beam_3, beam_4 example in https://forum.freecadweb.org/viewtopic. ... 50#p343116.
As far a I can understand, this seem to be a copy rather than a Link?

they're links to copies in memory. The principle of a (my) variant link is that : if you want to link to an existing part then you do a plain link. But if you want to have a part that is a modified version of the original — saved — part, then you first need to make a copy of the original part, modify the target parameters, and then link to that copy.

You might ask: why not copy the modified part directly ? There are many reasons, one of them being that that's not the way Assembly4 works. Another one is that when you copy an object into a document with other objects, some things might be renamed and then you won't know the real name of the target parameters. If you want to change the parameter Length but that has been renamed to Length001, how are you going to know ?

[paullee]

Understand the usecase ...

Hi @Realthunder, I haven't had the time to test the "Python extended version of App::Link" yet.

Some random thought - about Link has an array (btw how to access individual element e.g. in Python)

Would this works? Create special "Python extended version of App::Link" and with an array of element. And it add (again) the properties / the variables needs, and each elements in the array use these properties to derive their own placement / shape...?



It seems Link is powerful to create instances of an object with its own placement, and allow to scale its shape.

However, users want more
- a more flexible / automatic method to edit each elements' placement (my experiment to update an object placement, which become not accessible in its Link object)
- a more powerful method to vary each element's shape based on its Linked Object (like children of their parents

[realthunder]

Some random thought - about Link has an array (btw how to access individual element e.g. in Python)

Would this works? Create special "Python extended version of App::Link" and with an array of element. And it add (again) the properties / the variables needs, and each elements in the array use these properties to derive their own placement / shape...?

Well, those exposed Link array elements are ordinary Links in many sense, except that it can't be used to make further arrays. When you delete the parent Link, those elements will remain, and you can use them like normal Links. So I don't think it'll help with your use case.

If I undstandard correctly, your use case is better to be abstracted as some type of attachment method, so that it can be reused to work on any object with the AttachExtension.