There is a bug that happens once I try to join all the surfaces on the left side of the viewport simultaneously with a pre-selection. However, joining them one by one seems to work fine. Join the surfaces together to achieve a bug.3dm (850.5 KB)
The bug is also seen in this video at the 5:40 minute and at the 6:20 minute:
I suppose that Rhino finds it difficult to join the surfaces where both fillets meet at a zero angle next to the large truncated cone. Similar bugs happened recently on different models while working with revolved surfaces, so I opened this thread with the hope that this bug could be fixed for Rhino 7.
The ! _FilletSrf tool is typically very accurate, however, I noticed that sometimes it produces less accurate results. With regards to the singularity, the maximum gap between the two upper fillets is 0,0004730 mm, which is within the file’s tolerance, but is still big enough to cause the bug.
You can also see another example of inaccuracy related to the fillet seen at the 3:10 minute of my video, where the radius failed to be exactly 5 mm. This is die to the fact that the back fillet ended where the border of the top circle is located. when I place a vertical cylinder there and repeat the ! _FilletSrf command, Rhino produces exactly 5 mm fillet.
I have a request for future improvement:
You will notice that the lower fillet does not have a constant radius, because it’s Degree 3 with a huge amount of control points. I always wondered why Rhino will produce such inaccurate fillets along perfectly round surfaces. Is not it possible to fix that by figuring out a way for Rhino to build a Degree 2 revolved surface where it detects that the fillet goes around a true arc shape? That will solve so many problems with designing technical and architectural stuff.
Here is a simple example that proves the superiority of the so-called “revolved fillet” over the default one which is currently implemented in Rhino. Not to mention that is also has the bare minimum of control points. I used the blue arc to create a revolved fillet on the right model. The blue arc was extracted from the actual fillet of the left model. Request for a revolved fillet.3dm (251.7 KB)
First of all, the NURBS version of the fillet is not all that inaccurate. If you extract U and V isocurves from the NURBS Fillet and run simplifyCrv on them you will get true arcs. This means it is a simple matter to detect the surface reperesents part of a torus accurately. Similarly its easy to detect that a NURBS surface that has linear isocurve in one direction and a constant arc shape in the other is part of a cylinder. So it would not be hard for Rhino to convert the NURBS version to a torus. If you export that NURBS fillet to other CAD programs, many of them will recognize it as a trimmed torus.
Your example demonstrates there are situations where the extra precision of making the fillet as a torus is necessary so that Rhino doesn’t fall on its face when doing the trimming and joining. Fortunately, its not hard to make that fillet as a torus from the start.
Your example also demonstrates that sometimes its a better idea to not use a revolve. If you make surfaces that are planar as true planes instead of revolves you will also have less trouble with filleting and trimming and joining. In Rhino 8.2 the 5mm fillet in the back fails if the flat surface is a revolve but succeeds if its made as a plane. Again, Rhino should be able to recognize the revolve is planar but doesn’t.
Here is the geometry fixed so that Rhino can handle the filleting and trimming and joining. revolve.3dm (433.0 KB)
Before filleting, if the revolves are rotated so that their seams are not where the fillets will overlap, the joining can occur all at once. (The maximum edge tolerance of the closed brep is 0.0007.)
When adding fillets with _FilletSrf, I found that joining the resulting fillets first, then trimming the other faces to them can reduce the occurrences of micro edges when the rest of the faces/breps are joined.
