Performance improvements for PartDesign patterns (PR)

[chrisb]

Parallel execution may bring some relief, but I guess that there is a structural issue. The Python solution of Draft can't be 15-20 times faster than a C++ solution without an overall different approach.

[davidosterberg]

Parallel execution may bring some relief, but I guess that there is a structural issue. The Python solution of Draft can't be 15-20 times faster than a C++ solution without an overall different approach.

You are right. And I found the solution by studying how Part Cut does things. PD can now do the filter model as fast as your solution. The problem is that PartDesign also support overlapping patterns. This means that we will need a hybrid of this method and the old method. I am working on that.

[chrisb]

That sounds very promising. If it cannot be detected automatically, the advantage is still so enormous, that I would even welcome a user decision where he can choose which option he wants to use, including the danger that the fast variant can break the model.

[Jee-Bee]

Other CAD software have the same issue with the overlap. but still it they are much faster...

[davidosterberg]

I have pushed a new version. Now with huge boost in performance for simple non-overlapping patterns, like Chrisb's filter example.
Now the filter example executes in under 30 s (previously 1h +). Note that the model has to be modified slightly to avoid triggering the overlapping mode.**

performance_filter.png (236.67 KiB) Viewed 209 times

** The sketch attachment offset needs to be modifed so that there is no overlap between the tool shapes (unfortunately the tool shapes are not visible, which makes it hard for the user to notice the problem).

sketch_attachment_offset.png (62.75 KiB) Viewed 209 times

[chrisb]

Thanks! I think it is very well acceptable that the user has to consider certain preconditions when using this feature.

[davidosterberg]

I have added a property were the user can specify the overlap mode explicitly, in addition to the automatic detection.

overlap_mode.png (26.57 KiB) Viewed 150 times

Motivation:

1) On some models, such as the original Filter model. The overlap mode is triggered, because the tool bodies are overlapping. But in fact the features them selves are not overlapping so the non-overlap mode is suitable. Leading to a huge time saving.

2) If it is known that the patterned features are close, but non-overlapping, such as in the knurled knob example, explicitly selecting non-overlap mode can speed up the recompute time with 20%. Because the overlap detection itself is costly.

[chrisb]

[chrisb]

Do you know already the revision number for this feature? I would like to test and document it.

[davidosterberg]

Do you know already the revision number for this feature? I would like to test and document it.

It will only be merged (hopefully) after 0.19 has been released. The changes are local to one class and pretty straight forward so I don’t expect a long code review process. Perhaps it will be be in the development build in a few weeks. Until then the only option is to self compile. This is where it would be nice with the Greenhouse idea that was discussed a few months ago.