How a familiar modelling tool kept changing without losing the thing that made it useful
By Tim Elliot
There is a slightly odd thing about Rhino.
If you used Rhino 5 and opened Rhino 9 BETA today, you would know where you were. The command line is still there. Curves are still curves. Layers behave much as you expect. You can still type a command rather than hunt through a collection of icons to find it.
And yet, underneath that familiarity, an enormous amount has changed.
That is perhaps the most interesting part of Rhino's recent history. McNeel has rarely tried to reinvent the product simply to make a new release look new. Instead, Rhino has evolved by identifying the things that increasingly get in the way of designers and progressively removing them.
The result is less a succession of revolutions than a long, quiet evolution.
Rhino 5: a very good modeller meets a changing world
Rhino 5 arrived at a point when 3D modelling itself was changing.
For years, the fundamental attraction of Rhino had been wonderfully simple: it gave ordinary designers access to extremely good free-form surface modelling without requiring the investment—or the working methods—of the large industrial CAD systems.
The technology behind much of that is called non-uniform rational B-splines (NURBS), which may sound like scary mathematical gobbledegook to you and me. In plain English, think of it as a way of describing curves and surfaces very precisely.
You could draw accurately, build complex surfaces and solids, exchange files with almost everybody, and get on with the job.
But the jobs were changing.
Models were getting larger. Visualisation was becoming part of everyday design rather than something sent to a specialist at the end. Parametric design was moving out of universities and specialist practices. Meshes were becoming important rather than merely something you exported. And designers increasingly expected different software to talk to one another.
Grasshopper was perhaps the clearest sign of what was coming. What began as an intriguing visual way of generating geometry became a completely different way of thinking about design.
Instead of drawing the answer, you could describe the relationships that produced the answer.
That distinction would become enormously important.
Rhino 6: joining the pieces together
By the time Rhino 6 was being developed, the problem wasn't simply that Rhino needed more commands.
It needed its increasingly diverse capabilities to work together.
Grasshopper's incorporation into Rhino was therefore far more significant than adding another modelling tool. Parametric design stopped being something sitting alongside Rhino and became part of Rhino itself.
Rendering was changing too. Designers increasingly wanted to understand materials, light and form while they were designing, not after the modelling was finished. Rhino's rendering and display systems consequently became more important parts of the everyday modelling environment.
There were improvements to meshes, materials, display, documentation and the handling of increasingly complicated models.
None of those things necessarily sounds revolutionary in isolation.
Together, however, they changed what Rhino could reasonably be asked to do.
It was no longer simply a very capable NURBS modeller. It was becoming a platform in which several different ways of making and understanding geometry could coexist.
Rhino 7: another kind of modelling arrives
Rhino 7 brought one of the most visible changes in Rhino's history: subdivision modelling (SubD).
The problem SubD addressed is easy to understand without knowing anything about the mathematics.
Traditional Rhino surface modelling is extraordinarily precise, but precision can require planning. If you are designing something highly sculptural—a chair, helmet, shoe, consumer product or an organic enclosure—you may want to push and pull the shape until it feels right before worrying about exactly how every surface is constructed.
SubD gave Rhino a much more fluid way of doing that.
Start with a relatively simple form. Push it around. Add detail where it is required. Keep changing your mind.
The important bit was not simply that Rhino gained another modelling technology. It was that SubD could participate in the Rhino world.
A designer did not have to choose between intuitive form-making and accurate CAD as two separate universes.
That is a recurring theme in Rhino's development: rather than insisting there is one correct way to model, McNeel keeps finding ways for different representations of geometry to work together.
Rhino 7 also continued improvements in rendering, display, drafting, meshes, file exchange and existing modelling commands.
Again, evolution rather than wholesale replacement.
Rhino 8: reducing the friction
By Rhino 8, something else becomes noticeable in the development record.
A great deal of effort was going into reducing the number of interruptions between having an idea and changing the model.
PushPull is a good example.
The concept is hardly exotic: point at part of a model and push or pull it to where you want it. But making something that simple work reliably in a sophisticated CAD model is considerably harder than the gesture suggests.
Automatic construction planes address a similar problem. Designers constantly move between different orientations in three-dimensional space. Historically, we have told CAD software which plane we intend to work on. Increasingly, the software can infer it from what we are doing.
That may save only a few clicks at a time.
But a few clicks repeated hundreds of times a day matter.
Rhino 8 also improved UV mapping—the way a flat image is wrapped around a three-dimensional object—along with rendering, user-interface behaviour, drafting, meshes, SubD workflows, Grasshopper and interoperability.
There is a pattern here.
Mature software doesn't necessarily become better by acquiring ever larger menus. Sometimes the breakthrough is making the capabilities already present easier to reach.
Rhino 9 BETA: the software starts meeting you halfway
That trajectory is particularly apparent in the development of Rhino 9 BETA.
There are new commands, certainly, but there is also a great deal of attention being paid to existing operations: filleting, selection, Boolean modelling— combining and cutting solid forms—point clouds, SubD, drawing production, toolbars and numerous small pieces of interaction that collectively determine whether modelling feels effortless or laborious.
This is an important distinction.
A spectacular new feature is easy to demonstrate. Improving something a designer already performs fifty times a day can be far more valuable.
A better fillet doesn't sound terribly exciting until the old one fails on the model you need to deliver at five o'clock.
A better selection method sounds trivial until you are working with thousands of objects.
A better toolbar doesn't create any geometry at all, but it may help somebody discover a capability that has been sitting inside Rhino for ten years.
And that last point matters.
Rhino's problem may no longer be what it can do
It may be discovering that it can do it.
Rhino has accumulated an extraordinary range of capabilities. Some have buttons. Some live in menus. Some sit underneath other tools. Some are principally used from the command line. Some experienced users know almost instinctively; others can work in Rhino for years without encountering them.
This is one of the inevitable consequences of software that evolves rather than periodically throwing everything away.
The knowledge accumulates along with the capability.
For an experienced Rhino user that can be wonderful. Commands learned fifteen years ago still work. Muscle memory has value. You don't have to relearn your profession every time the software gets a new version number.
For somebody learning Rhino, however, the sheer depth can make discovery difficult.
That is an interesting problem because it isn't really a modelling problem at all.
It is an orientation problem.
From commands to workflows
Looking back from Rhino 5 towards Rhino 9 BETA, perhaps the biggest change isn't any individual command.
It is the gradual disappearance of boundaries.
The boundary between direct modelling and parametric modelling became less important as Grasshopper became part of Rhino.
The boundary between precise surfaces and sculptural modelling became less rigid with SubD.
The boundary between modelling and visualisation diminished as real-time display and rendering improved.
The boundary between different applications is being eroded by better file exchange, developer connections and technologies such as Rhino.Inside.
And the boundary between telling the software exactly what to do and letting it infer what you are trying to do is gradually moving too.
That is why describing Rhino's development simply by listing new commands misses much of the story.
The real progress is in workflows.
Evolution can be more useful than revolution
There is a temptation in software development to demonstrate progress by changing everything.
We've all seen it, particularly where annual release cycles create pressure to make each new version visibly different. Workflows are rearranged, familiar tools are moved, and users are asked to relearn things that were working perfectly well already—sometimes with remarkably little practical benefit.
It certainly makes the screenshots look different.
Rhino has generally taken another route.
Its development has been surprisingly Darwinian. New capabilities appear. Users test them. Problems emerge. McNeel's developers discuss them openly with users. Some ideas prosper, some change direction, and established tools are continually adjusted.
The public WIP, Serengeti and BETA discussions provide a fascinating record of that process.
You can see needs being identified before the eventual solution is polished enough to become an unremarkable part of the finished product.
That openness also explains why the boundaries between releases can sometimes be fuzzy. A problem explored during one development cycle may mature during another. A new command may appear alongside an older command that has been substantially improved.
Software development is rarely as tidy as the marketing brochure makes it appear.
And perhaps it shouldn't be.
What has actually improved?
For the person sitting in front of Rhino, the benefits of all this development are rather more straightforward than the technology behind them.
You can explore forms more freely.
You can change your mind later.
You can work with more kinds of geometry.
You can see a better representation of the result while you are designing it.
You can automate repetitive work.
You can build relationships rather than manually rebuilding geometry.
You can exchange information with a much broader digital design environment.
And increasingly, Rhino tries to remove the little administrative tasks that interrupt the act of designing.
None of those benefits requires the user to understand the underlying mathematics or software architecture.
Nor should it.
The best technology eventually becomes invisible.
The next challenge is discovery
Which brings us to an interesting place.
Rhino has spent decades accumulating capability without abandoning the working methods that made people like it in the first place.
That continuity is one of its greatest strengths.
It has also created a new challenge.
There is now more Rhino to discover than most of us know exists.
Even experienced users have their favourite corner of the program. A naval architect, jeweller, industrial designer, architect and Grasshopper specialist may all say they use Rhino every day while using remarkably different parts of it.
So perhaps the next stage in making sophisticated software easier isn't another attempt to make everything “simple”.
Perhaps it is helping people understand what is there, why it appeared, where to find it and when it might be useful.
That is the historical perspective we are interested in at 3D ANZ.
Not simply what commands were added to Rhino 9 BETA?
But:
What problems were people trying to solve?
How did Rhino's answer develop?
What became possible—or simply easier—as a result?
Follow that trail from Rhino 5 through Rhino 6, 7, 8 and now Rhino 9 BETA, and Rhino looks rather different.
It isn't a collection of more than a thousand commands.
It is a record of decades of designers finding new things they want to do—and a piece of software quietly learning how to get out of their way.