Dear @menno great for seeing some polishing on filletSrfToRail
sorry to tell there is some 20-dimensional overshots:
bamix_filletSrfToRail__bug.3dm (107.8 KB)
good luck to find a fast and robust fix - thanks - kind regards - tom
FilletSrfToRail seems to work better if you first Remove the multiknots from the curve.
I have created a ticket for this RH-98704. Running RemoveMultiKnot first on the curve indeed gives a result. It I think shows that finding the tangent rail on the other surface is not very well-defined as it oscillates quite a lot.
FilletSrfToRail is not the only Rhino command that chokes on geometry with MultiKnots.
That raises the question → Why is Rhino making curves and surfaces with MultiKnots in the first place.
One of the ways to get a nice FilletSrfToRail ius by projecting a simple curve to the surface and then with History turned on for both the Project and FilletSrfToRail commands you can edit the simple curve to influence the shape of the rail fillet result. The problem is that Project command makes a curve with multiknots.
However, removing multiknots from the rail curve is knot the only way to avoid the wild haywire result. I tried extending the Degree 5X1 surface by 1mm and then the result is more well-behaved.
That said none of these workarounds produce an accurate result. The edge of the resulting fillet deviates from the rail by a lot more than the document tolerance.
I’ve wondered the same about surfaces with multiknots whens the input curves do not have multiknots. My guess, based on some knowledge of NURBS math, is it’s done to obtain a closer fit of the surface to multiple input curves without an excessive number of control points. There are situations where it is not possible for a surface, which needs to follow various criteria, can exactly match multiple input curves. Surfaces from Sweep2 are frequent examples. Curves generated from these surfaces will then also have multiknots. A new thread may be more appropriate for a detailed discussion.
The tools in the VSR plug-in for Rhino 5 gave the answer many years ago. They were capable of achieving clean geometry within the file tolerance with a minimum amount of control points.
The multi-knots create a lot more control points. In the case at hand, 36 control points compared to 20 with the mult-knots removed .
And it rarely is more accurate. In the current case the curve without multi knots is closer to the surface than the one with multi-knots. Why would anyone think a curve with multi-knots, which has internal discontinuities, would fit better to a surface that has none?
That’s nonsense. After removing multi-knots the result of FilletSrfToRail has edges that are only slightly out of tolerance. Maybe 3 times the tolerance. Using the one with multi-knots as the rail the edges are way off in space. More than 10000 times the tolerance.
How did you determine this? I’m seeing negilgable difference in distance of the curves from the surface.
Original curve with multiknots - deviation from surface checked using Point Deviation with 200 points.
Curve with multiknots including multiknots removed - deviation from surface checked using Point Deviation with 200 points.
My mistake in reading your post. I’ve deleted that part of my post.
I seen vsr being mentioned as a great plug-in couple times now so I get curious searching for it, and see the second comment containing “Autodesk”
It just tells me all i need to know right there…
It was developed by a German team of programmers who previously had experience with ICEM, if I remember correctly. “Autodesk” bought the rights for the VSR plug-in a few years later, just a couple of months before discontinuing it for Rhino 5, in order to implement the technology in Alias. At least this is what I read about 10 years ago.
One of those programmers now creates the mightily Cyberstrak plug-in for Rhino 7 and 8.
Well Amen to that.
Thanks for the history lesson i will look into it.