It would also be useful to be able to specify a radius and arc angle instead of the second surface. Maybe this should be a different command, e.g., _FilletSrfFromRail.
Since there are 4 possible orientations of the fillet, I imagine the command also having flip and reverse options, similar to _OrientCrvToEdge
This sounds like the test command → testfilletsrfcrv
That test command has been available since Rhino5, I believe. Its pretty rough because heavenn forbid Rhino ever do anything to improve fillets, but it does pretty much what you describe.
Hi Steve, I think, if I understand you, allowing Sweep1 to use a curve on a surface (not just an edge) might be more generally useful, but I see it would need an accompanying tweak to OrientCrvToEdge or a new command to get the shape curve(s) in place.
testfilletsrfcrv and TestFilletSrfToRail have graduated to normal commands, _FilletSrfCrv and _FilletSrfToRail, respectively, in the WIP. I leaned about them from VSR end of Life- - #361 by Gijs
FilletSrfCrv requires 2 geometric input:
Surface near a curve
Curve near the surface selection point. The curve should be near, but not on, the surface.
Similar to FilletSrf, FilletSrfCrv output has a constant section.
The general solution for FilletSrfToRail is a variable fillet.
You’re right. Sweep1 with Align to surface is a more robust tool for this, and orienting the shape curve(s) is the most difficult part of the setup. As discussed in the thread in my first message above, if the rail is a natural edge of the surface, then a reference surface may also need to be created for the Sweep1.
Another workflow I use to create a “FilletSrfFromRail” for circular arc shapes from an edge is to _OffsetSrf the edge’s surface, then _Pipe the relative edge of the offset. The result is a surface/polysurface that can be trimmed to create a fillet to the starting surface.
I thought this had been requested before but couldn’t find such requests on the forum.
Thanks for that info.
I tried TestFilletSrfToRail in Rhino7 and was quite surprised at how well it appears to work. In the situations I tried it, TestFilletSrfToRail worked much much much better than VariableFilletSrf.
This is the first change I have found in Rhino7 that is a improvement and not a regression so I guess I will be spending a little more time with Rhino7 from now on.
This will also work for curves on surface as well as edges.
BTW, one way to evaluate the quality of the resulting surface is to offset the surface by say 5mm using the loose=yes option. Then offset it back (again loose) and compare to the original. It should be pretty close to precisely the original.
A good quality fillet will offset several orders of magnitude more accurately than a surface made using the edge as the rail for a sweep1.
Yes, depending on my goal, I may also use Silhouette on the pipe to create a 2nd surface for FilletSrf input so that the fillet is cleaner, including having natural edges tangent to each of the 2 base surfaces.
Apparently, I’ve misunderstood how Sweep1’s Align with surface works. From the help, I had thought
Align with surface (surface edge as rail only)
If the rail is a surface edge, the cross-section curve will twist with the surface edge. If the shapes are tangent to the surface, the new surface should also be tangent.
meant that the shape(s) needed to be tangent to the rail input for Sweep1, but your method proves otherwise. In fact,
The center-of-fillet rail produces a result that will back-and-forth OffsetSrf (Loose) with less deviation match than using the opposite side edge. 2e-05 vs. 0.171, respectively!
Well, the cross-section curve does have to be tangent to the edge that you want the sweep to run along.
You could also use your method of offsetting the surface and use the edge of the offset as the center rail for the fillet. The problem with that is that the edge will almost always have multi-knots and I don’t think there is a way to remove them. But anyway, you will get a fillet that is almost as accurate. Using a rail with multi-knots degrades the accuracy of sweep1 slightly. But if you have a way of removing the multi-knots from the edge definition then I’m guessing that method would be just as accurate.
Typically I make a fillet this way when the extend option in Filletsrf doesn’t go where I would like it to go. So the arc at end of the fillet that I am extending (by this method) is the cross-section curve and is guaranteed to be tangent.
As reported here, the changes made to _Fin (and _OffsetNormal), RH-67883, causing their output to be loose in the WIP, reduces the precision of the fillets using the workflow stated above. Both commands should have a Loose option. If the YouTrack issue doesn’t doesn’t exist, will you please add one?
Sadly, the real problem has been known for decades and despite many complaints over the years, nothing will be done to correct it.
The problem is that Rhino defines many of their geometry entities using multi-knots.
The method I described above for making that fillet was all about avoiding the problems caused by curves and surfaces that Rhino creates that have internal discontinuities. It is ridiculous to expect that a curve that lies on a smooth surface is best described by a curve that is specifically designed to be not smooth. Why not just define edges and pulled curves as polylines?
The Sweep1 command is one of the few geometry creating tools that does make geometry with no internal discontinuities, but when you feed it a rail that does have internal discontinuities then you have compromised the Sweep1 command’s ability to create an accurate sweep.
I don’t expect any changes to the Fin command will make any difference. To get an accurate result the user will still have to take many steps to trick Rhino into making and accurate smooth center curve to feed to sweep1.
I created a script that applies the Sweep1 method to create fillets. Input includes the arc cross-section’s radius, angle, and direction (sign of radius). Currently, only edges are allowed input for their respective faces.
