After not using this test command for a long time and forgetting its name, I just tried to use it now and it doesn’t seem to be working so well any more, it’s not producing a corner ball surface at all unless I enter a Radius bigger than what it desired, and in that case it makes an incorrect surface. Has anything been done with it since…oh I guess it was 2014?
Oh nevermind, I just had forgotten how to use it.
I’m intrigued now, what does it do and how to use it?
It creates corner ball fillets, useful for when using FilletSrf on a complex model instead of FilletEdge, so you don’t have to place a sphere and trim it out. You enter the radius desired and pick the surfaces that you’re filleting between.
Huh. And why isn’t it a regular command? Too hard to use? Fails on too many cases?
Sounds like something a lot of people could use.
We’re looking into making a real command. The difficulty is in describing exactly what it does, how to use it, why it might fail, and why it might succeed with an answer that might not be what the user wants.
Sounds like an open invitation to the forum! On the other two issues you guys are the experts, though I suspect forum participants can probably supply plenty of info and examples on what to look out for based on their experiences with the existing tools.
Hmm … I did not know about this (very useful) command.
After a couple of tests, using it seems straightforward.
At least for points where 3 fillets meet.
I think that cases with more than 3 fillets should be quite rare,
And anyway I have to build the regular fillets first, to be able to see which spherical patches are needed and where …
So far I see no particular problem here.
Or is there something more about it that I’m missing ? 
You are using it correctly. Success often depends on the pick location. If you already have the fillet surfaces, then the correct pick location is pretty obvious.
When there are more than 3 surfaces, the result is not always what you want. @JimCarruthers or anyone else, do you ever use this with more than three surfaces? The current thought is to have a command that makes a sphere tangent to three surfaces, with the option to trim the result to the sector defined by the arcs (what you get currently).
Hi @chuck, just wanted to mention that in case of eg. a pyramid with 4 or more sides, it works if the surfaces are picked in order, either clockwise or the other way around. If not the resulting sphere patch gets trimmed incorrectly.
_
c.
Yeah, that’s why the prompt asks you to pick the surfaces in order. Unless they are part of a brep and they all share one vertex, there’s no way to know what order to use. That’s also why I want to restrict to three surfaces.
Also, with more than three surfaces, there is no reason to believe that a sphere will fit. In FilletEdge, I do have the order, but I first do sets of three. In the rare case where centers are close enough together, I include more surfaces. SphericalPatch.3dm (119.7 KB)
I don’t understand why you are making this a separate command.
Any time that you have 2 fillets that intersect (i.e. they have a common base surface) and both fillets have the same radius at the edge point where they intersect (both radia have the same center point) that alone completely defines the 3 corner round situation. You don’t need to know anything about any other surfaces in the model to make the correct trimmed spherical surface when the above conditions are met.
The function of creating the spherical corner should be part of the FilletSrf command, because that trimmed sphere is the correct rolling ball fillet result when the user wants a fillet of a given size between 2 existing fillets of that same size.
Whenever 2 same size fillets intersect the user should be allowed to pick those 2 fillets and instantly the corner fillet should be produced. I don’t understand why you would want a separate command and allow the FilletSrf command to continue to fail to produce the correct filleting result.
And while were at it, the 3rd fillet in the 3 corner situation is also completely defined (if you have the first 2). So why is there not the option in FilletSrf to make that fillet as well? Why is the user asked over and over again to pick surfaces when they could just simply request that the program keep making all the (same size rolling ball) fillets that are already completely defined by the first 2 picks?.
because rhino fillets are a story beyond infinity 
but yeah please put this into fillets if this is its purpose. i have read around here that filets has some kernel which is actually not rhino native if i understood that correct was it siemens? but obviously this is one hot wish i keep stumbling over… make those fillets fillet what we want without having the fillets filleting the user.
Ah, OK
Yes, I only tried it on very simple surfaces.
But I think I understand what you’re talking about.
I experience that problem too often when using FilletSrf on real surfaces (in wireframe) … and I use that command a lot … 
Thanks
Hi jim - it’s not being made a separate command. It already is a separate command, it’s just being made accessible to users who don’t know about a hidden test command. Whatever the shortcomings of filleting in Rhino, some can be worked around with this function - that is a lot different bit of typing than rewriting FillletSrf to incorporate it, even assuming that is a good idea. i.e. You can have it now or ‘sometime’.
-Pascal
The question I asked was why would you continue to leave FilletSrf broken and introduce another command that is just a hack that doesn’t work very well. For one thing the 3 surfaces may not even all exist. there is no reason that they should.
If I have 2 fillets of radius 1 that intersect and ask FilletSrf to make a fillet of ,9 between them it will do this correctly. But if I ask for a fillet of 1 it will return “FilletSrf failed to create fillets.” That’s a serious bug that should have been fixed long ago.
You have already written the code to create the correct fillet but you
are not calling that code where it belongs. FilletSrf should be calling that code. If the user picks the 2 intersecting fillets and the radius of the 2 fillets are the same as the FilletSrf radius and the 2 arcs have the same center then the 3 surfaces that are parameter input for your function are all completely defined and known. There is no need for the user to tell you where those 3 surfaces are. Its easy to construct examples where one of the surfaces may not even exist (its been trimmed off) That doesn’t matter you should still be able to create the correct corner fillet.
There is no longer any excuse for FilletSrf to not produce the correct surface. You have written the code all you have to do is call it when the simple conditions are met.
I somehow interpreted this to mean that you did not understand why we are making this a separate command. My comments were an attempt to clear that up, not fix filleting.
-Pascal
You didn’t clear anything up. All you did is quibble that I used the wrong tense of the verb “make”. OK - so you have already made it a separate command. That doesn’t mean it makes a lick of sense.
What we are talking about is what does the rolling ball fillet of radius X between 2 fillet surfaces of radii X look like? The answer: The surface looks like part of a sphere. You have already the code written that generates this surface, Why are you trying to persuade me that FilletSrf should not call this code and produce the correct surface whenever the user attempts to fillet between fillets of the same radius with a fillet of that radius?
What you are saying is that you prefer that FilletSrf respond to that situation with “FilletSrf failed to create fillets.”
Help me out here. I’m truly seeking some insight on this.
I use filletedge almost exclusively, as I work as much as possible with CLOSED polysurfaces, and by the time I’m ready to fillet, I’ve created the properly closed polysurface, seemingly negating the use of filletsrf ? With that in mind, I agree, it should be an invisible portion of any fillet command, as long as the conditions are met as described, and NOT a “separate” command.
Thanks -
-C.
There are two reasons to use the FilletSrf workflow.
One, filletEdge simply can’t handle every possible filleting case, let alone when you have to make changes to an existing model.
Two, on complex models it can actually be faster and easier than trying to trim and join everything up in order to use FilletEdge. The first project where I actually purposely did this(after reading other jim going on for ages about its superiority) was a small watercraft where the deck had all sorts of features integrated into it and hatches trimmed out of complex shapes with offset gaps in the deck, sealing channels; and the parts all need minimum radii and draft angles, etc etc just fillets galore. I had no inkling what to even aim for to make solids for FilletEdge, it’s like is this detail a “fillet” or something that has to be done with a sweep or something? I made the major surfaces for the overall shape, added surfaces with draft angles where openings were to be, and just started FilletSrf-ing, and the details of the parts just “fell out” of the model in a very logical manner with clean geometry, meaning zero singularities and zero awkward “how to do I make a smooth corner where these 5 surfaces come together?” situations.
The problem with FilletEdge and many of the other solid tools in Rhino is that they force the user to learn to severely constrain their modeling output.
In other words, over time the user develops a long laundry list of things that past experience tells them will end in failure and thus should be avoided. As a result the realm of what they are willing to try to model in Rhino becomes more and more limited.
FilletSrf works well on polysurfaces. And works is the operative word here. FilletEdge doesn’t work on probably 95% of the polysurfaces that I create.
FilletEdge is a failure as a command because it starts with a false assumption. It assumes that there is a one to one correspondence between the edges of a polysurface and the fillets that can made to round those edges
There is no parity between the number of edges that the user selects and the number of correct fillets that should be made. Look at any program that does filleting well and count the number of edges and the number of fillet surfaces produced and you will see that they almost never match. When they do match its more of a coincidence than anything else. But nevertheless Rhino doggedly tries to produce one fillet for every one edge segment. And many users doggedly continue to either try to work with the incorrect and incomplete fillets that this failed algorithm produces or they try to limit their modeling to the limited cases where coincidentally the number of edges just happen to match the number of fillets.
If you do use FilletSrf to fillet a polysurface you may notice several things:
First you will notice that if your polysurface has a naked edge it doesn’t matter. Unless the gap is so wide that the fillet can’t reach across, it makes no difference at all whether the edge is well joined or not.
You will also notice that you are creating fillets that more or less follow along the edges. If you are observant you will notice that some places you end up with more fillets surfaces than edges and other places there may be more edges than fillets. Obviously any algorithm that tries to make one fillet for every one edge is going to get it wrong.
Another thing you will notice is that if you are careful and make surfaces that have good tangent continuity the end of the fillet you just made matches up precisely with the end of the next fillet in a string of fillets and each fillet joins the next one nicely.
Another thing you will notice is that the best place to click to pick the next fillet in a string of fillets is at the corner points of the last fillet you just made. So that brings up the question of why does the user even have to tell Rhino where the next pick points are? Why is there not an option in FilletSrf for Rhino to just make the next fillet and all subsequent fillets until it runs into the edge of a surface that has no neighboring surface to pick next. This would be a dead simple improvement to the filletSrf command that would make life a lot easier for the user.