What I'd like to see in Rhino 6

Continuing the discussion from Reseller Meeting BCN - Oct 2014:

Great comments, but I’ve moved this to a new topics since it isn’t related to the meeting logistics.

Hi Holo,

yes, haven’t I already heard something rumored about a T-Spline replacement from McNeel. This would make sense, when useful vanishing plug-ins are added by McNeel, I remember here Expander/Squish, Lino/Rhino 4.0 with 2D, and PowerSolids/Shelling/Filleting. I wonder, is Autodesk T-Splines for Rhino still in development?

I would like to see some artificial intelligent helping system (sounds mysterious) to get new customers faster productive. There are so many commands in Rhino, for a beginner it is often hard to choose from.



I would agree here as well, something I’ve asked for for a long time.

Also something I’ve asked for since like version 3… There is hope when I see the labs Array tool that Dale Fugier created as a “prototype” for V6 - assuming that this actually becomes the command and not just another add-on… One hopes that Extrude will follow the same path.


Perhaps @mikko can look at this. I’m not sure how difficult it would be.

This is an example of one many commands that could use a much improved UI. Added to YouTrack http://mcneel.myjetbrains.com/youtrack/issue/RH-27879

It is a big project. Don’t expect anything soon.

To my opinion it is far too late to invest in this discussion. At the reseller meeting we are two years after V5 release. During V5 WIP and shortly after the release, there’s been a lot of debate at the NG that was discouraging for several respected Rhino users that invested a lot of time in explaining their vision and problems.
I wait for results and hope for the best.

Another useful, vanishing plug-in, in addition to T-Splines, would be PointTools for Rhino. When Bentley dropped development on the Rhino platform for PointTools, it left many of my civic / city / corporate customers having to drop Rhino and by Descartes. They were VERY unhappy about that.

Hi! :slight_smile:
What about Clayoo! We forgot to add something?
Rafael del Molino
TDM Solutions SL

Adjustable Curve Blend. This is a great tool - but of course could be improved. Could we have an interface like Blend Srf? One or more blend curves could be adjusted with sliders and being able to input a blend factor (number) would mean that consistently shaped blend curves could be used. VSR shape has something like this.

1 Like

Everytime we attend a trade show we always hear the Autodesk sales guys saying that ‘Rhino creates crap geometry’. It’s my beleif that Rhino can create exceptionally clean geometry but there are a couple of things that would help significantly:

  1. More ways of creating surfaces explicitly (ie so we know the number of points, their position and the degree). Right now we can do this with Sweep 1 (Simple), Sweep 2 (Simple) and Edge Curves. It wood be good to have some options in Network Srf that would allow for explicit control where the starting curves allowed it.

  2. Solid Fillets. In 2006 we held a user meeting where I showed Solid Variable Fillets that were then in development in the run up to v4. Immediately after this meeting I submitted some files to McNeel where on some seemingly simple geometry the fillets would perform badly - giving ugly three sided corners and open edges. It’s fair to say that we’ve generated a good deal of training revenue by showing customers how to get around these issues but it would be great if we could see major improvements to filleting!

1 Like

Shelling. Shelling can be problematic in all software when faced with difficult geometry. Many of our customers needs solids but will accept something more ‘loose’ than a shell to within absolute modelling tolerance. I’m thinking of Jewellers and the like here - where the requirement is generally a solid for STL output. So would some sort of mesh shell (that approximated details to intricate to offset) be worth a look? A few years ago we knew of some customers who had (forgive the pun) shelled out on Freeform just to do solid offsets and then use the mesh patching in Freeform to convert the voxels to NURBS.

Phil - Does Autodesk really say that Rhino creates crap geometry??? Users create crap geometry, and from what I have seen, Autodesk users create more crap geometry than anyone else. If this highlights anything, it highlights a need for better education in the marketplace about the pprinciples of creating good geometry. One of the things that astounds me, is that in schools in New Zealand, they no longer teach how to construct a tangent, because the CAD software supposedly does that for them. This results in kids leaving school not really knowing what tangency is. So when they put two surfaces together in a way that does not preserve or create tangency in connecting surfaces, the first thing they do is blame the software. Whilst focus is placed on measuring reseller success by volume of sales (at cost plus a few dollars), ignorance in the marketplace will continue.

Yes, shelling, blending and fillets are problematic. But most of the problems result from end users with “magic silver bullet” perceptions of what the CAD software ought to be capable of. Most times these things go wrong in Rhino is because there is no valid solution based on the input geometry. Until customers think about their input geometry, their output geometry is always going to disappoint, and they only have themselves to blame, not the software, in my view.

1 Like

Well, even though I agree fully with you, I have to say that Rhino needs to start telling the user when it makes out of tolerance geometry. Or other bad stuff. Fillet edge in V5 makes lots of errors that V4 and earlier didn’t, in areas where it shouldn’t. And networksurface makes surfaces even if the curves are not touching, which is GREAT, but only if the user knows. And I think the CAD software could easily tell the user. Accurate edge curves are key, so if the surface deviates from them then the user needs to know. So this is an area I think V6 should focus on.

I always tell users to build surfaces using adjacent surface edges as input curves, rather than the input curves that users originally specified when creating the first surface.

What I recently found interesting was a customer who didn’t really get it that Rhino was more than a surface modeller, in that it was also a solid modeller. He had two intersecting valid closed polysurfaces. He exploded these and used the trim and join commands to achieve what was in effect a boolean union. Even though he was careful to use apparent intersections = No, the resulting polysurface had naked edges along some of the trimled edges. He assumed his input surafes were wrongly constructed and he asked me how to construct his original geometry better so as to avoid joining naked edges later. But his closed polysurfaces were cleanly constructed valid closed polysurfaces and the trims cleanly executed. I showed him how to boolean union two closed polysurfaces and he was absolutely delighted with the perfect result. However, I had to accept that using trim and join shouldn’t have created surfaces with poor edge tolerance in this situation. I meant to report this to McNeel tech support, but didn’t have time. It does tell me that although I generally believe it is the user not the software that is creating bad surfaces, in this instance I had to concede that it was the software :frowning:

Yes, splitting two surfaces against each other often result in errors, where a better result is achieved by first generating the intersecting curve and then using that to split both surfaces. It makes sense that it is a better workflow, but it should not be necessary. But again, the only way for this to improve is to supply the files to McNeel.


Yes, unfortunately some of the Autodesk resellers do keep trotting out this line. Personally I’d rather concentrate on the strengths of our product rather than the deficiencies of others but that doesn’t mean that there isn’t room for improving the performance of the core tools in Rhino before looking to add exciting new feature in v6. Mitch explained this beautifully to me a few years ago when he said something along the lines of ‘Rhino has become so stretched at the edges that it’s got thin at the centre’.

I’d agree to some extent that many ‘professional’ users have a lack of understanding about basic geometry and an inability to ‘set out’ their models but surely this is an opportunity for knowledgable resellers to include this type of content in their classes.

When, given identical geometry, solid fillets work in SolidWorks and not Rhino then that’s not attributable to the user.

Those are the examples that @chuck would like to see.

Yes, please send any of these directly to me, chuck@mcneel.com . The more I have, the easier it is to categorize them and figure out what to take on next. This is especially true of corner failures, but general fillet surface failures are good, too.