Here is a simple scenario where Rhino messes up fillets.
With no warning that the solid is no longer a solid, nor where the naked edges are.
So if you can not fix the bug then at least add a popup that tells the user that a solid is no longer a solid
in the same way as shelling does when it can’t make a solid. And highlight the naked edges. IMO it is very important to tell the user that a solid has been broken.
Thanks!
fillet bug.3dm (178.3 KB)
This sort of thing is really annoying. Considering how easily it’s handled by every other cad package. On top of the absence of a warning. I rarely use Rhino for fillets now. When I do I always check them for naked edges. I’m really hoping V6 takes a big step forward when it comes to them.
+1. Rhino is all but useless at filleting in any situation where faces aren’t 90 degrees to each other. If you are designing anything with draft angles, you are are required to do most of your filleting manually, at least at intersections between more than two faces. I still use my old SW 2005 license booted up in Windows XP to do most of my filleting. Personally, I won’t be upgrading to V6 if filleting doesn’t improve significantly. The cost of upgrading is really hard to justify when I’m forced to spend so much time on a process that is so easy in other programs.
The total absence of a response to this from McNeel is really troubling. I have been optimistic that there will be significant improvements. But now I’m not so sure. I really hope they aren’t choosing just to focus on the needs of the architectural community. At the expense of the needs of surface modelers.
But we know, for years now it is discussed: Rhino as is improving, will never perform fillet state of the art! the worst is that you drag certain defects from many versions, although there are enough improvements. We await the new version, let’s see if it will be better in the sector fillet.
Ugh, so much to say on this…
First, let me say that I think that a good portion of “fillet bug” threads posted on here are not exactly bugs per se…A lot of them are folks coming from a solid modeling background, and then trying to use fillet when what they should really be doing is trimming things back, blending surfaces etc. In short, there are a lot of instances where people are using fillet instead of learning the proper way to surface model.
This though - this is not one of those instances. This is a super simple case that should not cause issues with the model being watertight. I think the dirty little secret among those of use who do this for a living, is that for quite a long time now, for anything where fillets are a big part of a job, we will make the base surfaces in Rhino and then toss it over to some other software package to do the filleting. This is the state of affairs right now, but it’s bogus. And yes, I know, I know, those packages that we are using to fillet all cost more than Rhino. But to the people who say that I would say this - find me a current CAD package that does a WORSE job of filleting than Rhino. I don’t think you’ll be able to find one. Seriously, Pascal, John Brock, heck Bob etc - if you’re reading this - can you point out a CAD package that does worse than Rhino at fillets? I mean…do you guys want to do a head to head shootout with…TurboCAD???
What really frustrates me with the way that Rhino is being steered as a product overall is that there does not seem to be any grand plan other than “let’s see what’s on the feature request pile.” So, what happens is all these cool 3rd party developers step up and fill the gaps, and then they get acquired by Autodesk and then things become very very murky for those of us who rely on those products. But again, from where I’m sitting, it doesn’t feel like McNeel has any real plan for the core of the product - it says “NURBS modeling for Windows” on the box that I have - and that entire part of the product feels like no one is in charge, other than Pascal who is doing his level best to add items to the dev pile.
I really think that McNeel should have a product person on staff whose sole job is to steer the concept of “NURBS modeling for Windows” That is - someone who is keeping an eye on where things are going, developing new features rather than simply bug fixing old ones. I could rattle off a list of things that need complete overhaul/upgrade/implementation. For instance:
BlendSrf - as I pointed out in the past
MatchSrf - Seriously, this is the saddest command of all from the user perspective. Just getting into the command with multiple edges is awful. Who is in charge of this one? I’m going to send you a bunch of surfaces that need to matched on all four sides, and you can go crazy instead of me.
Something like Multi-Blend as was done in VSR
Better fillets (duh)
Point Editing - again, just do something like VSR did - in fact that interface can be improved upon, even though it’s 90% there. The Rhino point editing box is clearly something that was designed by developers, not users, and it shows.
Rebuild - It’s stuck in the dark ages. Again, look at VSR.
These are some CORE commands that anyone doing “NURBS Modeling for Windows” relies on day in and day out.
Now, you’re going to say to me “all those things are things that have been done in 3rd party applications, which cost money” - and what I would say back is “Yes! Absolutely! Please, McNeel, develop these things, and TAKE MY MONEY!” I would far far rather give my money to McNeel than to Autodesk. I would FAR rather give you that money, and know that the future of that functionality is tied to the future of McNeel and not some 3rd party vendor who may or may not be around come the next upgrade. Rhino is, in my opinion too cheap. Perhaps Rhino should come out with their own set of “Pro” plugins that add functionality. Rhino could become a base product, and a premium product. Or…?
Look, I know you guys are patching the holes and bailing the water as fast as you can, but is anyone actually steering this ship? Is someone in charge of the user experience?
-Sky
Sky, are you ready to sign up for that job?
I would seriously love that job Bob!
User Experience Advocate/Product Steering I think the business cards should say something like that 
Let’s talk. Am I going to see you in Utah?
Bob -
A lot of what this goes back to is what I learned working with the T-Splines guys - which is that the developers are not the users, and the users are not the developers. So a lot of times the T-Splines guys would have an idea, but have no clue whether it was useful to the user. One of the smartest things they did was hire Juan, whose sole job was to make the users look good and help people on their forum. That meant they had a bona-fide user (definitely not a developer) on the corporate side. This is a huge thing I see lacking in Rhino right now - the advice given out by McNeel here on the forum is almost always coming from guys who are developers, not users. It’s a totally different perspective. I think guys like Pascal do an amazing job of answering folks on here, but ultimately he’s a developer. That’s no back handed compliment - he does an amazing job, truly, but his perspective is not that of a user.
Yes, I’m going to Utah! I’ll see you then. Feel free to call me anytime too. I’m about to drive up the coast where cell reception is spotty but I’m generally available night and day!
-Sky
Yes please, get Sky to work on this!
And may I add one crucial point:
Trimmed edges of curved surfaces in Rhino tend to be overly complex making them nearly impossible to blend to class A quality (too many control points, too many spans).
VSR/Autodesk shape modeling has an edge rebuild function, but it is quite cumbersome to use (still better than nothing).
“Better” trimmed edges natively generated by Rhino would be awesome.
Cheers, Norbert
Let’s plan on talking more there…
Actual developer Lowell told me I’d been demoted, I see it’s true!
-Pascal
Hello,
In my time with Rhino I have to say that I would be happy forgoing 80% of the features on the toolbars if those freed development resources were used to beef up 20% of the surface modeling parts of the application.
In my opinion Rhino feels like looking at a dinner menu that has 1000 items on it, it’s unnecessarily overwhelming and intimidating to a user.
That issue is separate from a large amount of users in a specific vertical market being able to shift development objectives based upon the volume of similar feature requests, to make your way through that requires sticking to your core strengths and message rather than trying to be a refuge for those not wanting to be forced into a subscription model.
Improving the situation has to start back at the roots of the application with a thorough analysis of what McNeel wants Rhino to be and to start consolidating and strengthening the core feature set. The answer is not Rhino has to be whatever the customer wants it to be, that doesn’t work because it’s impossible to develop to that specification. Sometimes the answer to the user has to be, don’t use Rhino for that.
Being a lead on a variety of complex hardware UX / localization projects whose default interfaces were created exclusively by engineers in the past I can say that the UX process itself can be very painful for almost everyone involved if the parties go into it with the shields up, nobody ends up being happy in that scenario and you’re left with a product that is a jack of all trades and master of none. On the other hand when parties are able to set aside insisting on their way and work toward a common product experience objective the process and result can be very rewarding.
Norbert -
The ideal tool to use in this case is the VSR Surface Split command. I agree - the Edge Rebuild tool doesn’t work as well as one would hope. Have you used Surface Split? It took me literally years to clue into how well it solves this very problem, now I use it all the time.
-Sky
Sky, does that work with an arbitrary trimming curve? (i.e. not an iso)?
-Pascal
Pascal -
Indeed it does! Anything that crosses across the full length of the surface can be used. It gives you the deviation of the new surface from the original one, and also the deviation from the split object. If you have made nice surfaces and are not asking for something dumb, those numbers are usually very low - like in the thousandths of an inch. It’s rad.
-Sky
@skyg
of course I know Surface Split and I use it whenever possible.
It is limited to trims that lead to 4 sided patches though. Anything more complex than this needs the conventional trimming.
The biggest problem with Edge Rebuild in my experience is that it is near impossible to maintain g2/3 continuity of trimmed edges across surface borders.
@pascal
You can think of VSR/Autodesk Surface Split as ShrinkTrimmedSrf on steroids resulting in an untrimmed (4 sided) surface.
Norbert
After theoretically threatening Rhino with a Fillet Bro Down against TurboCAD, we got to thinking last night…would Rhino do better than TurboCAD at fillets in this case??? Uhhhhh…well this is embarrassing to say the least. Screen shots attached of the model fillet-ed in TurboCAD and then brought back into Rhino. The layout is slightly strange - there is a break in the fillet down the centerline, but at the end of the day, at least it doesn’t trainwreck and the model is watertight. So, rejoice everyone! Rhino’s Fillet command got you down? Just use a super bargain basement piece of CAD crapware to solve your woes! Cause that seems like a valid workaround to me. The $400 “Pro” version was used, but I’m betting that the $130 “Deluxe” package would do just as well.
So I guess the challenge remains McNeel folks - can you find a CAD package that does worse than Rhino at fillets?