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.
Why can't OnShape generate "oversize" chamfers? (Question/Feature Request)
aidan_fraser
Member Posts: 13 ✭✭
Hi all, sorry if this is a repost/resurrection of an old topic but I couldn't find much discussion about this.
Often I find myself wanting to use a sweep shape or chamfer distance that onshape doesn't accept. It's "too big", it has self-intersections around tight radii and I get an error message about self-intersection.
Another post by an onshape employee on another thread suggested this was to avoid generating bad geometry. I understand that we want to avoid bad geometry, but this isn't a satisfying explanation for me.
I'm trying to understand the rationale for the restriction. There are reasonable cases when a sweep or chamfer intersects itself. Often, increasing the sweep radius, or reducing the size of the sweeping shape can be a good workaround, but often it's an unacceptable compromise.
One common case I find quite a bit is trying to model a routed cut along a curved edge that has some radii/details that are smaller than the routed shape. I think it's a reasonable thing to want to do, because it's easy to imagine and describe the part. And manufacturing it can be really simple with a standard router.
I accept I may being totally naive here, but it feels like OnShape could accept "oversize" chamfers, at least in some simple cases (e.g. circular radii), since manually modelling these cases usually doesn't require a lot of thought, just lots of clicks and extra planes and sketches.
Thoughts?
Often I find myself wanting to use a sweep shape or chamfer distance that onshape doesn't accept. It's "too big", it has self-intersections around tight radii and I get an error message about self-intersection.
Another post by an onshape employee on another thread suggested this was to avoid generating bad geometry. I understand that we want to avoid bad geometry, but this isn't a satisfying explanation for me.
I'm trying to understand the rationale for the restriction. There are reasonable cases when a sweep or chamfer intersects itself. Often, increasing the sweep radius, or reducing the size of the sweeping shape can be a good workaround, but often it's an unacceptable compromise.
One common case I find quite a bit is trying to model a routed cut along a curved edge that has some radii/details that are smaller than the routed shape. I think it's a reasonable thing to want to do, because it's easy to imagine and describe the part. And manufacturing it can be really simple with a standard router.
I accept I may being totally naive here, but it feels like OnShape could accept "oversize" chamfers, at least in some simple cases (e.g. circular radii), since manually modelling these cases usually doesn't require a lot of thought, just lots of clicks and extra planes and sketches.
Thoughts?
0
Comments
Hopefully this explains what I mean. (Check out the source doc if you like)
This "over-sized chamfer" feature would make OS more expressive, and parameterized models would be more robust (bigger parameter space). Maybe I'm a weirdo? Wouldn't be the first time! But it's hard to imagine this not helping a lot of OS users.
I am pretty naive to the way OS is implemented, but I imagine it's possible to detect intersections in the swept chamfer and internally split the chamfer into two separate chamfer operations.
Maybe I should try to make a prototype FS feature?
Is it rude to continue to bump this post? 🫢
I would love any kind of response from Onshape staff here, even if it's brief. Surely I'm not alone in running up against "maximum chamfer" limits?
Someone should create an improvement request.
@aidan_fraser the reason we don't do it is because Parasolid does not allow it. Thanks for the improvement request. This is the first time anyone has asked for this capability, so until it has been reviewed and implemented it might be quicker to create a custom feature if you need this every day.
There have been requests in the past to make chamfers more robust in general. This case here appears to be only one example. Just yesterday have I had an issue with chamfers not resolving after a change in geometry, even though the very area where it would create said Parasolids issue was not actually part of the model, because another piece of the solid took that place, and the edges involved would never actually meet. But since it is not uncommon (also with other software), I worked around it by modifying the model history. That would, however, mean that if - for any reason - someone wanted to change the geometry again, it could be necessary to modify model history again. That is not the spirit of a feature driven modeling approach. So, even if Aidan's case is one of a kind, the underlaying issue of chamfers failing whenever their edges meet (even if it was in a distance that is no longer part of the model at the time of editing), is still generally important. It appears direct editing modellers have less or no issues with this case.
Thanks for the response both of you.
@neilcooke I’m surprised I’m the first to raise this. I’m willing to accept maybe I use chamfers strangely. It’s possible there’s an easy workaround i’m not thinking of, or “macro chamfers” are typically modeled without using the chamfer feature.
When you next get the opportunity, please ask customers who use chamfer whether they run into the restriction and if so, how they deal with it. Would love to know. Maybe it’s not been reported because simply it’s always possible to “manually” build a self-intersecting chamfer, and there are “bigger fish to fry”.
Regarding “parasolid does not allow it”, I take that to mean it would be non-trivial to implement, which I have respect for.
It seems, then, that for this capability to be prioritized, it would have to be shown to be valuable enough to customers to be worth the effort. If so, I’ll try to gather evidence of this, although I am not well connected with OnShape users. I’m currently just going on instinct, and I’m willing to discover I’m wrong to think this would be a valuable improvement.
Also, just spitballing, perhaps an implementation could try to use parasolid’s “native” chamfer and, if it fails, retry with a more sophisticated approach that support self intersections. I’m happy to try to implement a featurescript prototype of that “sophisticated” approach, to show its potential value (and that it’s possible). Not sure how far I’ll get to be honest. I am a software developer by trade, but I’ve found the foundations of FS difficult to grasp so far.
@martin_kopplow ”direct modelling editors have less or no issues”
Yes, this is absolutely correct. Blender, for example, is sometimes inperfect but almost always allows chamfers to be pushed into self intersection.
For posterity, here is the improvement request I submitted:
https://forum.onshape.com/discussion/25801
(thanks to @s1mon for the nudge)
Have you tried to use the face blend feature in chamfer mode? I wonder if would be able to handle this...
Unfortunately, it doesn't. With or without tangent propagation.