View Issue Details

IDProjectCategoryView StatusLast Update
0000052FreeCADBugpublic2009-12-22 10:30
Reporterunauthenticated Assigned Towmayer  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Product Version0.9 
Target VersionFixed in Version 
Summary0000052: Three fillets produce 5 radiuses
DescriptionHi,

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
TagsNo tags attached.
FreeCAD Information

Activities

2009-12-12 16:33

 

cube1.fcstd (Attachment missing)

Jriegel

2009-12-12 18:42

administrator   ~0000053

Im not quit sure what you mean with 5 edges. For me the result looks OK

???

2009-12-12 18:58

 

newcube.fcstd (Attachment missing)

unauthenticated

2009-12-12 19:00

viewer   ~0000054

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

Jriegel

2009-12-12 19:26

administrator   ~0000057

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?

???

wmayer

2009-12-14 08:53

administrator   ~0000065

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.

wmayer

2009-12-21 09:36

administrator   ~0000074

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.

Jriegel

2009-12-21 09:57

administrator   ~0000077

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

wmayer

2009-12-21 16:40

administrator   ~0000079

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()

Jriegel

2009-12-21 20:16

administrator   ~0000080

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!

wmayer

2009-12-22 09:21

administrator   ~0000083

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/

Jriegel

2009-12-22 10:28

administrator   ~0000086

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....

Jriegel

2009-12-22 10:30

administrator   ~0000087

Works for me as expected.

Issue History

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 Jriegel Note Added: 0000053
2009-12-12 18:44 Jriegel Status new => assigned
2009-12-12 18:44 Jriegel 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 Jriegel 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 Jriegel Note Added: 0000077
2009-12-21 16:40 wmayer Note Added: 0000079
2009-12-21 20:16 Jriegel Note Added: 0000080
2009-12-22 09:21 wmayer Note Added: 0000083
2009-12-22 10:28 Jriegel Note Added: 0000086
2009-12-22 10:30 Jriegel Note Added: 0000087
2009-12-22 10:30 Jriegel Status assigned => closed
2009-12-22 10:30 Jriegel Resolution open => no change required