Interesting, how do you propose this variants should be saved? embedded in the assembly file? If you add further features to the original file, how will they be updated in the variants? Unrelated cuestion: how did you make the "Variables" object, it seems very handy
Code review of merged Link3 branch
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- adrianinsaval
- Veteran
- Posts: 5553
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Code review of merged Link3 branch
Re: Code review of merged Link3 branch
There is a difference in paths behaviour between realthunder's former FreeCAD-asm3 branch and the current FreeCAD-0.19-pre developper version: -asm3 saves relative paths for linked files while -pre saves absolute paths.
I did the exact same thing in both:
-asm3:
-pre:
I did the exact same thing in both:
- create 3 new documents
- save them as asm, part1, part2, in the same directory
- close them
- re-open them
- create a link (not Assembly4 link, a pure App::Link) in asm
- assign the linked part as part1
- create a link in asm
- assign the linked part as part2
- save
-asm3:
Code: Select all
<Property name="LinkedObject" type="App::PropertyXLink" status="256">
<XLink file="part1.FCStd" stamp="2019-10-28T07:10:15Z" name="Part"/>
</Property>
Code: Select all
<Property name="LinkedObject" type="App::PropertyXLink" status="256">
<XLink file="/home/hubertz/Documents/3Dcad/FreeCAD/Data/Test_v0.19/part1.FCStd" stamp="2019-10-28T07:19:20Z" name="Part" sub=""/>
</Property>
realthunder, did you modify the paths behaviour between -asm3 and 0.19-pre ? I think that the -asm3 behaviour was better, unless there is a way to specify absolute/relative paths manually.
Re: Code review of merged Link3 branch
well, first I think that these are still App::Link objects, so no, not in the assembly. What should be stored in the assembly is the base file and the variables that shall be modified to produce — on the fly, in RAM, not on disk — the variant. The point is also that this should be forward compatible, meaning that files produced today shall be usable in 10 years. But in 10 years people are going to come with new ideas. While it would be quite easy to come up with a solution for today, this would not scale well.adrianinsaval wrote: ↑Mon Oct 28, 2019 3:58 am Interesting, how do you propose this variants should be saved? embedded in the assembly file?
The minimum would be to store in the assembly:
- the base file : Path
- a boolean that it's a variant of that base file : isVariant
- the variant type (because I'm sure other people will have other use-cases in mind) : VariantType
- the variables that shall be changed and their values : a list
Code: Select all
<Object name="Part_1" Extensions="True">
<Properties Count="18" TransientCount="0">
...
<Property name="LinkedObject" type="App::PropertyXLink" status="256">
<XLink file="part1.FCStd" stamp="2019-10-28T07:10:15Z" name="Part"/>
</Property>
<Property name="isVariant" type="App::PropertyBool" status="256">
<Bool value="false"/>
</Property>
...
</Properties>
</Object>
To be clear, the primary use-case would be for families of parts, to be used as library, therefore the occurrence of the base part changing should be rare. When that happens, a command "Reload Variant" is needed, that re-fetches the base part from disk, and re-applies the variants changes to it. Thus, if additional functions have been added, they will be included also.adrianinsaval wrote: ↑Mon Oct 28, 2019 3:58 am If you add further features to the original file, how will they be updated in the variants?
They're FeaturePython objects. They're the poor man's spreadsheet. In a new document, try:adrianinsaval wrote: ↑Mon Oct 28, 2019 3:58 am Unrelated cuestion: how did you make the "Variables" object, it seems very handy
Code: Select all
App.ActiveDocument.addObject('App::Part','Model')
vars = App.ActiveDocument.getObject('Model').newObject( 'App::FeaturePython', 'Variables' )
vars.addProperty( 'App::PropertyBool', 'Variant', 'Variables' )
vars.Variant = True
vars.addProperty( 'App::PropertyFloat', 'Length', 'Variables' )
vars.Length = 10
vars.addProperty( 'App::PropertyEnumeration', 'Size', 'Variables' )
vars.Size = ['M2', 'M2.5', 'M3', 'M4', 'M5', 'M6']
vars.addProperty( 'App::PropertyString', 'Comment', 'Variables' )
vars.Comment = 'This is a comment'
Re: Code review of merged Link3 branch
@Zolko
This macro sounds similar ("Part Family"):
https://forum.freecadweb.org/viewtopic.php?f=22&t=18437
https://www.freecadweb.org/wiki/Macro_Alias_Manager
But i guess you would like to involve App::Link? Therefore i guess for App::Link being able to represent the same linked feature (shape) more times, each time the linked feature having a different property (like length) set? If each App::Link feature would need an underlying copy of the shape, then i don't see much benefit, compared to i guess using the approach 'Part Family' macro uses. If App::Link could work in a way, to build a representation, without needing an underlying copy after. Then i guess that might be worth exploring in the future.
P.S. Anyway, one practical/theoretical question, now that more than one developer has an in-depth understanding of the App::Link. Should App::Link and App::Part be merged in the future, or not?
This macro sounds similar ("Part Family"):
https://forum.freecadweb.org/viewtopic.php?f=22&t=18437
https://www.freecadweb.org/wiki/Macro_Alias_Manager
But i guess you would like to involve App::Link? Therefore i guess for App::Link being able to represent the same linked feature (shape) more times, each time the linked feature having a different property (like length) set? If each App::Link feature would need an underlying copy of the shape, then i don't see much benefit, compared to i guess using the approach 'Part Family' macro uses. If App::Link could work in a way, to build a representation, without needing an underlying copy after. Then i guess that might be worth exploring in the future.
P.S. Anyway, one practical/theoretical question, now that more than one developer has an in-depth understanding of the App::Link. Should App::Link and App::Part be merged in the future, or not?
Re: Code review of merged Link3 branch
No, of course not. App::Part is a "group", App::Link just creates a link or reference to another object.
However, I think realthunder also created a "LinkGroup". This LinkGroup is basically a replacement for App::Part. So, I think he does in fact intend to merge the functionality of LinkGroup into App::Part.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Code review of merged Link3 branch
The merge is more or less done in my branch here, by merging some App::LinkGroup features into App::Part, so we'll be seeing App::Part more in the future.
Re: Code review of merged Link3 branch
And is App::LinkGroup more or less Assembly oriented, or it affects PartDesign (and other aspects of FreeCAD) too?
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Code review of merged Link3 branch
LinkGroup offers a coordinate system without any side effect. So when you add a sketch with external geometry, those referenced objects won't be added as a side effect. This may be good or bad depending on the use case. App::Part can achieve similar effect by adding Link. So my plan is to bring App::Part up front for the end user. And leave LinkGroup at the background for power user/developers. PartDesign body remains the same.
Re: Code review of merged Link3 branch
Would any of this work.
- Add PartDesign Body to App::LinkGroup.
- Add a combination of PartDesign CoordinateSystem and Part Cylinder to App::LinkGroup.
Re: Code review of merged Link3 branch
are these families pre-built ? What I would like is to create a "Part" — rather: to link a Part — that is created on-the-fly, and whose variables can be modified even after creation.triplus wrote: ↑Wed Nov 13, 2019 10:42 pm This macro sounds similar ("Part Family"):
https://forum.freecadweb.org/viewtopic.php?f=22&t=18437
https://www.freecadweb.org/wiki/Macro_Alias_Manager
Yes, if a new Variant is created, then it cannot share its geometry with the original, so yes, there needs to be some kind of copy. The difference is that the Variant would only be created in RAM, not on disk. Another difference is that you could create Variants of assemblies, where only the assembly would be duplicated, not the parts, and then in the variant assembly the same parts would be positioned differently, no shape would be copied.triplus wrote: ↑Wed Nov 13, 2019 10:42 pm But i guess you would like to involve App::Link? Therefore i guess for App::Link being able to represent the same linked feature (shape) more times, each time the linked feature having a different property (like length) set? If each App::Link feature would need an underlying copy of the shape, then i don't see much benefit, compared to i guess using the approach 'Part Family' macro uses.
And the point is: App::Link can already do exactly that, except that it cannot be saved to disk.
And I'm not the only one asking for this feature:
joe.belladonna wrote: ↑Sun Nov 17, 2019 3:34 pm My intention was to use FreeCAD to draw one parametric chipboard cabinet, and import it several times but with different dimensions.
...
I need to somehow, unlink parts after import so I can change dimensions. I don't care if that would be simple copying, and I don't care about file sizes. I just need to avoid to draw cabinets all over again for every single cabinets case I need to build.