Continuing the discussion from Rhino 9 WIP Available Now!:
This is still a fail when I tried it. The fillets and base surface don’t join.
Here is another example of the same sort of thing.
extend_error_1mm.3dm (51.1 KB)
The fillets are made but the fillets and base surfaces don’t join. The source of the problem is that the fillets should only be extended on the one end. Extending on the end that needs to join is causing join failures.
Also the fillet in the middle should not be a revolve surface. A NURBS surface made in Rhino8 is much more accurate than this revolve surface.
The whole purpose of using a revolve surface is that it is more accurate than a NURBS surface when applied correctly. When a revolve is used where a NURBS a more accurate it becomes a liability instead of an asset.
I see that at R=1, thanks.
Revolve surfaces are only used if the rail curves are arcs within document tolerance. The middle input surface has constant radius iso-curves, which means that the fillet can and will be simplified into a revolved surface. And even then, actual revolve surfaces only end up in the fillet when they are singular, i.e. a trimmed sphere.
That is not a very good test. For that to work the deviation from an arc would have to be many orders of magnitude smaller than the user tolerance and even then its doubtful. In order for the two rails to be part of a torus shaped fillet they have to be arcs that have the same axis, but also the fillet needs to be tangent to the base surfaces. This last condition is the most important. If FilletSrf is now creating fillets that are not tangent that is likely to cause trouble for users.
This pic shows the difference between the fillet Rhino9 makes and the one that Rhino8 makes.
FilletSrf has always made extremely accurate fillets that have good G1 continuity. This is important when making complex models with many layers of overlapping fillets.
Here is an example file showing how the revolve filet poor G1 continuity makes overlapping fillets also inaccurate:
inaccurate_revolve_fillet.3dm (112.6 KB)
Thanks @jim, this is very helpful. I agree that this is not good enough and will keep at it. I’m going to either limit the use of revolved surfaces to trimmed spheres only, or see that similar quality checks are made that are applied in FilletEdge when fillet surfaces are simplified to revolved surfaces.
Some context for why it is what it currently is: I was going off of what you said earlier in the other topic:
A trimmed sphere object is what is used by every CAD program that does rolling ball (arc) fillets well. A nurbs surface with a singularity is more than likely to cause downstream problems for the user when it works and as far as I can tell it mostly does not work.
There is similar functionality in FilletEdge/BlendEdge/ChamferEdge, simplifying fillet surfaces that qualify with revolved surfaces. I’ve just tried your extend_error_1mm.3dm file with FilletEdge but it does not simplify the middle fillet to a revolved surface, so that is a clear indication that I should revisit how FilletEdge does this.
I think you misunderstood what I said earlier about using a trimmed sphere when two same size fillets collide.
What I am talking about in this thread (this bug report) is the use of a fillet that is part of a torus. Rhino defines both a sphere and a torus as a revolve surface (RevSurface), but other than that they are separate topics.
The enclosed file illustrates the accuracy of a true torus which is going to be at least a million times more accurate than the document tolerance. The extreme accuracy that you can get from a torus but can’t get from a NURBS surface is beneficial to the user because future operations involving that fillet can also be expected to work with extreme accuracy.
The extreme accuracy is what makes it valuable.
Most often a torus shaped fillet is going to be created when the two base surfaces are a revolve and a plane where the axis to the revolve surface is normal to the plane. Less often it could be a fillet between two revolve surface that have the same axis.
The enclosed file illustrates how the user can construct a torus fillet using standard Rhino tools. The rail curves are already arcs so there should be no need for arc fitting. The rail curves lie precisely on the base surfaces (deviation of less than 1.0e-12).
revolve_fillets.3dm (2.8 MB)
If the user makes a revolve surface using the deformable option the accuracy is going to be much less, but I would think that any user that wants a deformable revolve would also want the fillet to be deformable and not a true revolve.
I don’t think I misunderstood. Both trimmed-sphere and part-of-a-torus fillets are obtained by attempting to simplify a fillet surface to a surface of revolution. There was a long-outstanding request to convert fillet surfaces in FilletSrf to a surface of revolution, similar to what FilletEdge already does.
What you’re demonstrating in the revolve_fillets file is what is now possible with FilletSrf directly. I have tuned the tolerances with which fillet surfaces are converted to be in line with FilletEdge. This will be in the next WIP version. To be clear, your earlier contribution about accurate/inaccurate fillets has been adressed with this; the extend_error_1mm file no longer converts fillets to a surface of revolution. (The original trim/join problems you reported are also solved btw).
As for accuracy: a torus can be converted without loss of any accuracy to a NURBS surface, meaning that they both represent the exact same shape. What is different between the two is the angular parameterization. For a torus this is a constant parameter describing the rotation around the axis. Such a constant angular parameter is not possible for a NURBS surface, which is why there are two methods to convert Surface to Nurbs parameters and vice versa.
Surface.GetSurfaceParameterFromNurbsFormParameter
Surface.GetNurbsFormParameterFromSurfaceParameter
The request was to replace the less accurate fillet that FilletSrf made in Rhino8 and before with more accurate revolve surface. There is a difference between “replace” and “convert”.
This was reasonable request because a Rhino user could replace the fillet themselves. All they had to do is delete the fillet and make a revolve surface based on their knowledge of the underlying geometry.
If your code is not producing the same accuracy that a Rhino user can do on their own, there will be complaints. I included an example in my last post. The revolve surface that I created in that file is about 1 million times more accurate than what your code produced. That was last week’s Rhino9, hopefully its fixed in this week’s wip.
The same thing applies to the trim sphere that can be used when two same size fillets collide. Any Rhino user that knows what they are doing has been able to construct that trimmed sphere themselves for more than 25 years. The only reason that users had to do it themselves was because no Rhino developer has bothered to code the operations that the users were using. Users do appreciate that this now being worked on but it is not unreasonable to expect that it will be done at least as well as users can do for themselves.
Replace or convert, the end result is the same: where tolerances allow, the fillet surface is now a revolved surface. I fully agree with doing things at least as well as users can do themselves, and when that is not the case I am here to listen and improve.
Just to re-iterate: the example you provided has been taken care of, and I hope you will test the next version to see if you agree. If not, we’ll keep iterating to a solution.
Last but not least, I’m also doing this for Rhino users who are maybe less proficient, and may struggle to replace a fillet with a trimmed torus or sphere.
Just downloaded the latest.
There were three files I posted each with an example of a different error but they are all working beautifully now. This is really moving along nicely.
Excellent, thanks for your testing efforts!