Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Performance Tips for Sweeps?
dave_cowden
Member, Developers Posts: 475 ✭✭✭
Hey, all:
I'm working on a thread generator, which has pretty realistic threads, with a profile swept along a helix.
Yes, before you say it, I know that most people don't want real threads. But this generator is for people who do, for example, because they are 3d printing things, or making lens caps, etc.
Anyhow, i'm using the cool startTimer and printTimer function to look at execution time ( kudos @ilya_baran for those functions).
I'm seeing ( not surprisingly ) that creating the thread geometry, and then subtracting/adding that to the base part are accounting for all of the time.
Does anyone have overall pointers/tips/tricks for how to speed things up?
Here is a picture of the geometry, nothing fancy:
By way of example, this code takes about 1.2 seconds (creating the thread forms by sweeping a profile over a helix):
The helix and sketch is what you'd guess from the above picture...
And this takes about 1.2 seconds ( subtracting the threads from the parent body )
I'm working on a thread generator, which has pretty realistic threads, with a profile swept along a helix.
Yes, before you say it, I know that most people don't want real threads. But this generator is for people who do, for example, because they are 3d printing things, or making lens caps, etc.
Anyhow, i'm using the cool startTimer and printTimer function to look at execution time ( kudos @ilya_baran for those functions).
I'm seeing ( not surprisingly ) that creating the thread geometry, and then subtracting/adding that to the base part are accounting for all of the time.
Does anyone have overall pointers/tips/tricks for how to speed things up?
Here is a picture of the geometry, nothing fancy:
By way of example, this code takes about 1.2 seconds (creating the thread forms by sweeping a profile over a helix):
<div> var sweepId = id + "_sweep1";</div><div> opSweep(context, sweepId, {</div><div> "profiles" : sweepItems,</div><div> "path" : qCreatedBy(helixOpId, EntityType.EDGE)</div><div> });</div><div> var qSweeps = qCreatedBy(sweepId, EntityType.BODY);</div><div> </div><div> printTimer("Sweeps-1");</div>The helix and sketch is what you'd guess from the above picture...
And this takes about 1.2 seconds ( subtracting the threads from the parent body )
<div> startTimer("FuseSweepsToParent");</div><div> var fuse = id + "fuse";</div><div> opBoolean(context, fuse, {</div><div> "tools" : qUnion([parentBody, <span>qSweeps </span>]),</div><div> "operationType" : BooleanOperationType.UNION</div><div> });</div><div> printTimer("FuseSweepsToParent");</div>My assumption is that this is just 'complex geometry' and that there is not much that can be done. But if there are any 'expert' tricks that can be used, please let me know!0
Best Answers
-
elif
Onshape Employees Posts: 53 
Hi Dave,
I'm afraid there's not much you can do at that level as you guessed. It is indeed complex geometry. The good news is we do have some ideas on how to improve the performance of thread creation at a lower level, and we will get to it..eventually
Stay tuned.
5 -
lana
Onshape Employees Posts: 706
One way to make Boolean operation faster is to overshoot. If you are merging or subtracting bodies with complex overlapping geometry, resolving that takes time In this example the difference between slower and faster sweep is the profile (Sketch 2).6
Answers
I'm afraid there's not much you can do at that level as you guessed. It is indeed complex geometry. The good news is we do have some ideas on how to improve the performance of thread creation at a lower level, and we will get to it..eventually
Just wanted to make sure I wasnt missing anything. One thing I can do is provide an option for the user to reduce the complexity of the profile. I'm not sure how much that will help, but i'll run a couple of tests to find out. My anecdotal experience has been that the complexity of the profile doesnt impact performance as much as the pitch of the helix.
Turns out, a tiny difference in geometry makes a 10x performance difference!
This is a cross-section of a profile swept on a helix. Note the highlighted flat portion of the profile. This took 0.3ms to create:
Now, here is the same profile, but with a 3 point arc there instead of the flat section:
Shockingly, this small difference increases build time to a whopping 2.86 seconds!!! That's nearly 10x longer!
As a third test, i added another point, connected by lines instead of an arc. The question is; was it the extra point or the arc and the resulting surface:
Performance on this is 0.9s-- 3x slower than without the intermediate point, but still nearly 3x faster than the arc.
@ilya_baran @elif, is this something you would have expected? I certainly didnt!
Anyway, these tests helped me understand how to give the user a speedier option. In this case, just letting them opt out of that little relieve radius saves 10x!
Here are the performance timings for the 'fully complex' profile:
And here are the timings for the 'simplified' profile:
we have about 3 seconds more time on the complex profile, and it is split roughly equally between creating the sweeps and fusing them to the parent, as shown in bold.
The "TrimSweeps" item is very, very interesting too. After i create the helix by sweeping the profile, i trim it on top and bottom with two cylinders, so that it is limited to just the threads I want to create. That's a boolean subtraction-- starting with the sweeps and REMOVING the cylinders.
What's really really interesting is that while it takes 1.5 seconds to fuse sweeps to the parent body, it takes only 0.2 seconds to subtract TWO cylinders from the sweeps. Its really strange that subtracting is so much faster than the union. This is repeatable too. Its such a huge difference that i considered re-organizing my code to try to subtract from some huge cuboid instead of unioning.
For those coming after me-- I did some performance tests using the 'overshoot' idea Lana suggested, and I can confirm that it works.
In my tests, performance was 10-15% faster overshooting vs having booleans with a 'line on line' mate. Its not a huge difference, but it is a repeatable difference that can add up if your feature has many booleans.