Wish: FilletSrfToRail with constant radius

Geometric input for the new _FilletSrfToRail are

  1. Curve that is on a surface
  2. Surface that contains the curve
  3. Second surface on the fillet side

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 would be a faster solution to create the model on the right for Bug: Sweep1 Align untrimmed Surface Edge

Thank you

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.

1 Like

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.


1 Like

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:

  1. Surface near a curve
  2. 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.

That should work in theory but the twists and seam in a pipe create problems.

Here is a file showing the way I do that using the Sweep1 example from TomP

The steps in the file are:

  1. duplicate the edge and rebuild to a high number of points say 100 (make sure the result is well within tolerance)

  2. create a perpendicular Fin from rebuilt edge to the center of the arc (distance 20mm in this case) Remove multi-knots from the fin surface.

  3. sweep1 along the fin edge (the center curve of the fillet) Use the Align with Surface option in sweep1.

fillet_along_edge.3dm (98.8 KB)

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.

1 Like

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.

@pascal ,

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?

Thank you

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.

1 Like

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.

spb_FilletSrf_fromRail spb_FilletSrf_fromRail

spb_FilletSrf_fromRail.py requires spb_OffsetNormal.py that can also be used on its own as an alternative to _OffsetNormal but with options for simplification, tolerance, etc.