FilletEdge in Rhino WIP is not very different from earlier versions at this moment of writing, so fillets that consume surfaces completely will not work correctly.
Rolling ball fillets with FilletSrf however do support this in current WIP
FilletEdge in Rhino WIP is not very different from earlier versions at this moment of writing, so fillets that consume surfaces completely will not work correctly.
Rolling ball fillets with FilletSrf however do support this in current WIP
why is there always this feature discrepancy between _filletEdge and _filletSrf ?
samples:
_filletEdge identified surface of revolution / parts of tori first - now 1 or 2 versions later _filletSrf can do so too
reversed story for consuming surfaces - _filletSrf now can do it, _filletEdge cant’t …
because the two don’t share the same code base currently. From what I have understood, Menno’s goal is to change that eventually.
wow, that sound s like twice the similar work
and twice of error tracking and code maintenance
Indeed, which is one of the reasons I want to change that. This change will not go into v9.
![]()
I hope that fillets will be updated in the final version of Rhino 9 because sometimes filleting sharp edges can be very time consuming and you have to use 5 different commands to get the desired shape.
Can you share maybe an example of what you’re having problems with, and your solution method with 5 different commands? I’m always curious to know what is working and not working, and maybe the collective knowledge and experience of the forum can help you out streamlining your workflow.
sure i make short videos for all type fillet failure and send them here today
That is fantastic. Be sure to include the 3dm files too ![]()
From a non-programmer user perspective:
Since this would merely put the two filleting commands on the same (already existing) code base, I find the news that we will have to wait for v10 to make this happen (presumably several years away) rather underwhelming.
I understand your sentiment, and I wish it would be different. But unfortunately this is not the case, and from a programmer’s perspective: it is not as easy as you may think. Changing something like this has been likened by others to open heart surgery, rather than stacking a few lego blocks differently, to make it all work.
Thank you for expanding on this.
It was exactly why I put the disclaimer “non-programmer” in my post.
I suspected there would be reasons for this delay and hope and trust you these are “good” reasons.
Note that this doesn’t mean Filleting will not improve before that happens.
I think it would be a terrible idea to put FilletSrf and FilletEdge under the same command. The only way to make that work would be to compromise functionality. With FilletSrf you can make a fillet between two spheres that don’t touch. How will you ever do that with a tool that requires picking edges?
That said, It would be nice if FilletEdge made fillets with the same accuracy that FilletSrf does. The two commands have completely different methodology for users telling Rhino what Fillets they want, but in the cases where they can make the same fillet both should be accurate. I personally never use FilletEdge because even when it seems to work you never know when it will sabotage your model by inserting inaccurate surfaces with poor continuity.
It would also be nice if FilletSrfToRail and FilletSrfCrv functionality was included inside FilletEdge command also, but it would be terrible if those were not also available as standalone commands.
Don’t worry, the commands won’t change in their approach. It’s just that for example rail-finding is a big part in both commands, and the code for rail finding could, I think, be shared between the two commands (currently it is not). Similarly, FilletSrf will have continuation across edges that connect faces with G1+ continuity (“continue across faces” in Rhino WIP) - and it would be nice if FilletEdge could do the same.
That is how I understood @menno .
Your example model is garbage. When I check the edge tolerance it says 0.1. The model has fillets with radii that are smaller than that.
Also the cylindrical hub at the heart of the model is composed of more than a dozen small surfaces that have horrible continuity between each small piece. See what EdgeContinuity shows:
The nice thing about FilletSrf is you can extract and delete all those surfaces with bad continuity and drop in an accurate cylinder to replace.
You don’t have to worry about making edges, just start filleting to connect the cylinder to the other surrounding surfaces.
2X.3dm (3.9 MB)
Rhino 9’s new fillet tools look like a huge step up setback corners, tangent-continuation, and revolved-surface simplification are going to save a ton of cleanup time. The improved FilletSrfCrv results also look way more predictable compared to Rhino 8. Excited to try these workflows on real projects!