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|
|Status||closed||Resolution||no change required|
|Summary||0000052: Three fillets produce 5 radiuses|
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.
|Tags||No tags attached.|
Im not quit sure what you mean with 5 edges. For me the result looks OK
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.
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.|
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_
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.)
# Create a fillet on one edge
doc.Fillet.Base = doc.Box
__fillets__ = 
doc.Fillet.Edges = __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.Fillet1.Base = doc.Fillet
__fillets__ = 
doc.Fillet1.Edges = __fillets__
doc.Fillet.ViewObject.Visibility = False
# Create a fillet on two edges directly
doc.Fillet2.Base = doc.Box
__fillets__ = 
doc.Fillet2.Edges = __fillets__
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 ,. Unfortunately with no replies.
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.|
|2009-12-12 16:33||unauthenticated||New Issue|
|2009-12-12 16:33||unauthenticated||File Added: cube1.fcstd|
||Note Added: 0000053|
||Status||new => assigned|
||Assigned To||=> Jriegel|
|2009-12-12 18:58||unauthenticated||File Added: newcube.fcstd|
|2009-12-12 19:00||unauthenticated||Note Added: 0000054|
||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|
||Note Added: 0000077|
|2009-12-21 16:40||wmayer||Note Added: 0000079|
||Note Added: 0000080|
|2009-12-22 09:21||wmayer||Note Added: 0000083|
||Note Added: 0000086|
||Note Added: 0000087|
||Status||assigned => closed|
||Resolution||open => no change required|