I was tutoring a workshop yesterday morning (just after updating to the new SR11) and a very simple FilletEdge operation failed. It seams that Rhino thinks that the edge loop that defines the perimeter of the planar surface that gived us the problem doesn’t define a planar and closed loop; if you try to explode the polysurface and rebuild the problematic surface it offsets numerically something close to *whatever**10^-16 units but visually you can see that the new rebuilt surface is displaced from the original and the surrounding surfaces.
To solve the problem I had to explode the polysurface and delete the problematic surface. Then I draw a straight line that I extrude later. I trimmed that surface with the naked edges in my polysurface and finally joined everything together. After that, the FilletEdge command worked like a charm… I suppose that this is not a problem of the FilletEdge command but the polysurface object (the object was modelled straight from boxes, joined together using boolean unions and refined using fillet edges).
Please, find attached some images of the bug and an explanatory *.3dm file.
Yep, the edges of that surface have been pulled out of tolerance by some operation, don’t know what… If you extract the surface and look at the info you see:
Edge Tolerances: 0.00207899 to 0.177214
median = 0.0937936 average = 0.0923589
If you RebuildEdges you see the surface change immediately visually, plus info now says:
Edge Tolerances: 0 to 1e-05
median = 0 average = 3.33333e-06
Perhaps you can recreate the object step by step and find out where it went bad.
I exploded the object, rebuilt all edges, deleted the bad surface, joined then capped the hole… Fillet then works.
That is what I was saying (I just said that to fix the solid you just need
to delete de faulty face and build a new one)…the thing is that the solid
was created using only “clean” boxes (using the _Box commands), fillets and
one face displacement (using ortho and TAB), that was because I was worried
about those edges…there was no further manipulation, etc. And the worst
thing is that almost 35 people (attending the workshop) had the same issue.
I don’t know if this case shows any misbehaviour of the BREP engine used in
rhino and helps solving any future problem in the Rhino6 development…in
any case here it is.
Well, again, they would need an exact “cookbook” recipe for producing the problem - i.e. recreate the model step-by step to get to the problem area… I think it’s the only way to find this problem. The “face displacement” seems the likeliest candidate in this case.
Ok, not having a lot of time now to make complete guide about how I got there (it will need the tracing of the initial curves that I used for guidance from some pictures, every step in the creation of the metal sheet, etc.), but seriously, I have modelled quite more complex things in Rhino and stitching boxes (morphed or not) together and filleting them was never a problem. I just thought that uploading some captures of the final state and the faulty model could be enough for giving some help.
Thanks for your comments. As soon as I have enough time to make a better description of the issue I will post it.
