Performance improvements for PartDesign patterns (PR)
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Performance improvements for PartDesign patterns (PR)
davidosterberg , could this option be considered an array option, meaning that for reliable operation all features will need to be the same. That might mitigate the Topo-naming issue.
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
Re: Performance improvements for PartDesign patterns (PR)
davidosterberg wrote: ↑Tue Feb 23, 2021 3:52 pm As mentioned in the OP, topological naming issues is a risk with this PR, since it is changing things around under the hood. I did some testing with recomputing a Topo-sensitive test model created with master. Indeed this is a real issue. That I don't know how to manage best.
1) We could ignore the problem and say that FreeCAD has no guarantees with respect to topological naming.
I almost wrote this hypothesis myself when I considered option 1. I didn't mention it because I don't know how the @realthunder TNP-solution would react to to naming just changing by itself like this.
@realthunder, what do you think?realthunder wrote:
It is interesting. I might give it a shot.Could you test the behaviour of your PR with Linkstage3 branch of @realthunder?
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Performance improvements for PartDesign patterns (PR)
Looks like your PR here might conflict with what I have implemented in my branch. There are some significant overall changes with PartDesign in my branch. It allows for multiple solids, so there is no need to check for pattern touching base at all. In other word, I have already changed it to behavior like draft array, that is, fuse all instances in one go. In case you do want to selectively exclude some instance (not necessarily based on whether it touches the base or not), there is a way to achieve that. When you create the pattern as a new solid as shown in the linked post, it will produce a compound instead of fuse further improving performance.
As for topo naming issue, my topo naming framework will add some prefix to distinguish each instance of the pattern. So it won't be of much a problem there, although it does have some performance impact on large patterns.
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
Re: Performance improvements for PartDesign patterns (PR)
Good to know. This PR is actually removing the check for if the pattern touch the base (for performance reasons). It is all about improving performance within the existing framework. It can therefore be merged now, so that the community can enjoy the performance boost. It sounds like your changes, including the skipping code, can be applied later. Also see my Draft array skipping PR (#4430) for my proposal for a syntax for skipping copies in patterns. Again within the existing framework. Perhaps the same syntax can be supported in the PartDesign Transformed class.realthunder wrote: ↑Thu Feb 25, 2021 9:43 am Looks like your PR here might conflict with what I have implemented in my branch. There are some significant overall changes with PartDesign in my branch. It allows for multiple solids, so there is no need to check for pattern touching base at all. In other word, I have already changed it to behavior like draft array, that is, fuse all instances in one go. In case you do want to selectively exclude some instance (not necessarily based on whether it touches the base or not), there is a way to achieve that. When you create the pattern as a new solid as shown in the linked post, it will produce a compound instead of fuse further improving performance.
Regarding the multiple solids in one body, I am not sure if that has been properly discussed yet. I can certainly see the practical advantage of this. But it also goes against the name "Body" and "PartDesign", words that are singular. It is a part of the quest to making PartDesign self sufficient. I see that you also give PartDesign support for a CSG workflow. Again in the same spirit. A quest that I can sympathize with. I was even more in this camp a few month ago, when I was more a beginner. Now it does not bother me so much that I have to switch to Draft for some operations. What bothers me a bit, is that the division of responsibility for the different workbenches is blurred.
Excellent. No need to deal with this in this PR then.As for topo naming issue, my topo naming framework will add some prefix to distinguish each instance of the pattern. So it won't be of much a problem there, although it does have some performance impact on large patterns.
Last edited by davidosterberg on Thu Feb 25, 2021 12:58 pm, edited 2 times in total.
Re: Performance improvements for PartDesign patterns (PR)
Large patterns (for example a die cut plate) are i think for every CAD software hard.
In most compays i worked the create 2 configurations of a part one for part with all holes for the part drawing and one (default) with a simplified small pattern just for graphical purposes.
In most compays i worked the create 2 configurations of a part one for part with all holes for the part drawing and one (default) with a simplified small pattern just for graphical purposes.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Performance improvements for PartDesign patterns (PR)
The upstream Draft link array actually can skip instance. Simply set the array property 'ExpandArray' to true, and each element will be exposed as child objects grouped under the array. Hide any child you don't want. And that's it. You can optionally collapse the array again by reverting 'ExpandArray'.davidosterberg wrote: ↑Thu Feb 25, 2021 10:37 am Also see my Draft array skipping PR (#4430) for how my proposal is for a syntax for skipping copies in patterns. Perhaps the same syntax can be supported in the PartDesign Transformed class.
Well, naming is certainly not a strength of FreeCAD. Comparing to most other CAD software, FreeCAD Body is more of a Part, while the multi-solid support I am aiming for is kinda equivalent to multi-body in other CAD.davidosterberg wrote: ↑Thu Feb 25, 2021 10:37 am Regarding the multiple solids in one body, I am not sure if that has been properly discussed yet. I can certainly see the practical advantage of this. But it also goes against the name "Body" and "PartDesign", words that are singular. It is a part of the quest to making PartDesign self sufficient. A quest that I can sympathize with. I was even more in this camp a few month ago, when I was more a beginner. Now it does not bother me so much that I have to switch to Draft for some operations.
Re: Performance improvements for PartDesign patterns (PR)
I have split this topic, follow-up is here: https://forum.freecadweb.org/viewtopic.php?f=8&t=56055 .
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
-
- Posts: 529
- Joined: Fri Sep 18, 2020 5:40 pm
Re: Performance improvements for PartDesign patterns (PR)
I fixed the preview logic. It is now working as before. However, the pattern still accepts this as a successful transform. Unlike the old behavior that threw an error.
- Attachments
-
- new_behavior.png (64.36 KiB) Viewed 2605 times
Re: Performance improvements for PartDesign patterns (PR)
The skipping was already possible before, it was only the dialog which prevented it. With a change later in the properties what you show could be achieved without throwing an error. The new behaviour was several times asked for.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.