View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000052 | FreeCAD | Bug | public | 2009-12-12 16:33 | 2009-12-22 10:30 |
Reporter | unauthenticated | Assigned To | wmayer | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Product Version | 0.9 | ||||
Summary | 0000052: Three fillets produce 5 radiuses | ||||
Description | Hi, I create box. Then I do a radius on one edge. In next step I do radius in oposite edge. Finally I want radius on edge which is between them. I expect only three edges with radius. But I get 5. Please see attached file. Best regards Peter | ||||
Tags | No tags attached. | ||||
FreeCAD Information | |||||
2009-12-12 16:33
|
|
|
Im not quit sure what you mean with 5 edges. For me the result looks OK ??? |
2009-12-12 18:58
|
|
|
Hi, sorry I do not consider the output correct. Or I do not understand how it should work. I have applied fillet function three times and every time on one edge. After that I can see 5 edges with radius. Is this ok? Please have a look at file newcube.fcstd. Fillet1 has two edges with radius. Then I have applied fillet on edge1. But on fillet2 I can see also radius on edge7 and edge8 (edges 7 and 8 are from original fillet1). Maybe one more note: why first objects do not have index. like first created box is box and not box1. I think it would be better to have one structure of name for all objects. Best regards Peter |
|
Mhhh, in my opinion the output is correct... Try to use for the second Fillet a different radius!? Do the same radius on all edges make no sense to do it in two operations!? Or make me a drawing what result you think is correct? ??? |
|
I think Peter is right. When applying the fillet operation on one edge we get the fillet on this edge. When applying the fillet operation on a parallel edge which is on the same plane as the first edge the result is still ok. But when applying the fillet operation that connects the first both edges we have the fillets applied to five edges instead of three. So, from my point of view this is something the user doesn't expect. |
|
I had again a look on this issue and debugged our source code carefully. So, IMO this is an issue with the underlying OpenCascade library and I didn't find anything to circumvent this problem. It seems that if you try to make a fillet on a selected edge the OCC algorithms adds automatically all other edges that are > C1-continuous with adjacent edges. It only seems to work as expected if you have selected all wanted edges for the very first time instead of adding them step by step. |
|
Mhh, I still dont get how the operation shut look different as they does.... Fillet operations are not mathematically well defined. Its always a kind of matter of taste how and algorithm sort and patch faces. Especally when it comes to different fillers overlap each other... So for me - still no bug till someone gives me an exampel how it _shut_ look like!? Jürgen |
|
The script below makes it clear. The object Fillet1 and Fillet2 should be identical but they're NOT! (This example demonstrates the issue with only two edges.) doc=App.newDocument() doc.addObject("Part::Box","Box") # Create a fillet on one edge doc.addObject("Part::Fillet","Fillet") doc.Fillet.Base = doc.Box __fillets__ = [] __fillets__.append((12,1.00,1.00)) doc.Fillet.Edges = __fillets__ del __fillets__ doc.Box.ViewObject.Visibility = False # Create a fillet on one edge of the above result. # This creates an objected with THREE filleted edges doc.addObject("Part::Fillet","Fillet1") doc.Fillet1.Base = doc.Fillet __fillets__ = [] __fillets__.append((8,1.00,1.00)) doc.Fillet1.Edges = __fillets__ del __fillets__ doc.Fillet.ViewObject.Visibility = False # Create a fillet on two edges directly doc.addObject("Part::Fillet","Fillet2") doc.Fillet2.Base = doc.Box __fillets__ = [] __fillets__.append((12,1.00,1.00)) __fillets__.append((6,1.00,1.00)) doc.Fillet2.Edges = __fillets__ del __fillets__ doc.recompute() |
|
Ahh, now I see what you mean! It follows the edge as long there is a tangent follower! The algos has to do so, because how shut it stop the fillet at the arc? That would be a very ugly crumbled thing. There fore the algos did the right thing. Not exactly what we told him to do, but the only other option is to fail in such a case! |
|
From an algorithmic point of view this might be the correct behaviour. But as a normal user this is something I would not have expected. That's the point! BTW, this behaviour was already topic in the OCC forum twice [1],[2]. Unfortunately with no replies. [1] http://www.opencascade.org/org/forum/thread_2286/ [2] http://www.opencascade.org/org/forum/thread_3668/ |
|
I disagree. Show me one use case where you need such wired behavior? Ending a fillet on tangent edge would most likely end in a completely collapsed end-face and highly unstable! Fillets are used in mechanical design a certain way. And again there is no Use Case. This discussion is anyway pointless. If you want to change that behavior you have to re implement the Fillet algos.... |
|
Works for me as expected. |
Date Modified | Username | Field | Change |
---|---|---|---|
2009-12-12 16:33 | unauthenticated | New Issue | |
2009-12-12 16:33 | unauthenticated | File Added: cube1.fcstd | |
2009-12-12 18:42 |
|
Note Added: 0000053 | |
2009-12-12 18:44 |
|
Status | new => assigned |
2009-12-12 18:44 |
|
Assigned To | => Jriegel |
2009-12-12 18:58 | unauthenticated | File Added: newcube.fcstd | |
2009-12-12 19:00 | unauthenticated | Note Added: 0000054 | |
2009-12-12 19:26 |
|
Note Added: 0000057 | |
2009-12-14 08:48 | wmayer | Assigned To | Jriegel => wmayer |
2009-12-14 08:53 | wmayer | Note Added: 0000065 | |
2009-12-21 09:36 | wmayer | Note Added: 0000074 | |
2009-12-21 09:57 |
|
Note Added: 0000077 | |
2009-12-21 16:40 | wmayer | Note Added: 0000079 | |
2009-12-21 20:16 |
|
Note Added: 0000080 | |
2009-12-22 09:21 | wmayer | Note Added: 0000083 | |
2009-12-22 10:28 |
|
Note Added: 0000086 | |
2009-12-22 10:30 |
|
Note Added: 0000087 | |
2009-12-22 10:30 |
|
Status | assigned => closed |
2009-12-22 10:30 |
|
Resolution | open => no change required |