Rhino’s Quiet Evolution

How a familiar modelling tool kept changing without losing the thing that made it useful

There is a slightly odd thing about Rhino.

Its evolution is visible in places beyond the modelling commands: how a licence is shared, how the software reaches your computer, and how a design leaves the desktop for a client’s hand. Those quieter changes matter to the person trying to get work done.

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 3: a quieter change beneath the surface

The story starts before the first commercial Rhino. In 1992, a company called Applied Geometry approached McNeel about bringing its AGLib NURBS geometry library into AutoCAD. Alias Research was also a customer of Applied Geometry, alongside several other organisations. McNeel first worked with Applied Geometry on AccuModel, then developed the modeller that became Rhinoceros. McNeel’s own history sets out that sequence.

Alias agreed to buy Applied Geometry in 1994. McNeel had already licensed AGLib and was building geometry expertise of its own; it brought Dr Dale Lear into the team and began substantial in-house geometry development. McNeel records receiving its last AGLib update in 1995. By the time Rhino 3 arrived in November 2002, the story was about technological independence as much as visible buttons. That statement is nothing more than an interpretation of the documented sequence.

For the person opening the box, there was also a very physical part of the experience. Rhino 1, 2 and 3 CDs sat in a pocket at the back of a substantial printed User’s Guide. Rhino 3 was the last version supplied that way. A manual you could put beside the computer had value of its own when learning unfamiliar modelling ideas.

Rhino 4: the capability moves into view

Rhino 4, released in February 2007, brought a much more visible expansion. In an interview that year, Robert McNeel was asked about the more than 800 improvements listed for the release. He pointed to new 2D layout tools that mattered to people preparing work for a laser cutter, and universal deformation tools that could change a shape more freely. Read the 2007 interview.

Universal Deformation Technology was a particularly important shift. A designer could bend, twist or stretch existing geometry, or use a simple control cage to reshape a more complex collection of objects. The model no longer had to be reconstructed piece by piece whenever its overall form needed to change. That made experimentation more practical: a proportion or gesture could be tested while preserving much of the work already done. McNeel’s UDT guide describes the deformation tools.

CageCreates a control cage around objects.

TaperGradually scales geometry along an axis.

TwistRotates geometry progressively around an axis.

MaelstromSpirals geometry around a centre.

StretchLengthens or shortens geometry along an axis.

SplopCopies, scales and orients objects onto a surface.

CageEditDeforms captured objects by editing a control cage.

FlowMaps objects from a base curve or surface to a target.

BendDeforms geometry around an arc.

One designer’s essential addition might be another designer’s rarely used command.

That is why the large number is less interesting than the variety: Rhino was becoming useful at more stages between making a form and communicating or fabricating it. The growth also foreshadowed the later challenge of discovering which tools were already there.

The presentation changed as well. Rhino 4 shipped in a DVD case, after the thick book and CD combination of the earlier releases. The physical package grew smaller as the software’s range grew larger.

Rhino 5: a very good modeller meets new ways of working

The Gumball feature first officially appeared during the Rhino 5 development cycle, offering direct interactive movement, scaling and rotation on selected geometry in the viewport.

This was one of the many changes in 3D modelling approach heralded by Rhino 5. The evolution of Grasshopper was another.

For years, Rhino’s fundamental attraction had been straightforward: it gave ordinary designers access to precise free-form surface modelling without requiring the investment or working methods of the large industrial CAD systems.

Much of that capability is based on non-uniform rational B-splines (NURBS), a mathematical way of describing curves and surfaces precisely. Designers could draw accurately, build complex surfaces and solids, exchange files with other systems and proceed with the job.

Rhino 5 developed that established modeller while the range of work around it expanded. Models were becoming larger, visualisation was moving into everyday design work, meshes were increasingly important and designers expected software to exchange more information.

Grasshopper was a particularly significant part of that change. Its visual definitions described the relationships that produced geometry, allowing variations to be generated by changing inputs rather than redrawing each result. Direct modelling and parametric modelling were becoming complementary ways of working.

Rhino 5 also brought a broad collection of new commands and improvements across modelling, editing, display, drafting and documentation. The selected toolbar icons provide a compact sample rather than a complete catalogue.

During Rhino 5’s life, McNeel moved to electronic delivery. From February 2015, licences could be sent by email and the software obtained online. The installer no longer had to travel across the world in a box. McNeel’s account of the packaging and release history record the shift.

Rhino 5 was also the release that reached the Mac. Rhino 5 for Mac shipped in June 2015 after years of work adapting a Windows-born modeller to another operating system. For Mac users, the significant change was that Rhino had become available on their own platform. McNeel dates the Mac release to June 2015.

Another small but far-reaching companion appeared during this period. By 2013, iRhino 3D let people carry a Rhino model to an iPhone or iPad and show it away from the modelling workstation. It was a viewer, not a replacement for the desktop application, and it made the model easier to share in a meeting or on site. McNeel’s 2013 newsletter already lists iRhino 3D.

Licensing had its own evolution. The earlier LAN Zoo let a workgroup share licences from a server on its network; McNeel documents its support for Rhino 2, 3 and 4. Zoo 5 was completely rewritten in January 2013. Zoo compatibility and McNeel’s chronology provide the dates.

Rhino 6: joining the pieces together

Rhino 6 extended that licensing story with Cloud Zoo. A team could share its licences through Rhino Accounts without maintaining its own in-house licence server, and a designer could sign in on another computer. McNeel presented it as a new Rhino 6 option in 2018; the LAN Zoo remained available. This was an improvement to access and administration rather than to geometry, but for a small practice it could change the daily experience of using Rhino. McNeel’s Cloud Zoo note sets out the new option.

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

Rhino 8, released in October 2023, combined substantial new modelling tools with improvements to many established operations.

PushPull enabled direct editing of faces by pushing or pulling them while Rhino handled the surrounding solid geometry. Automatic construction planes reduced the need to set a working plane manually by aligning it to suitable geometry as the user worked.

Unified mesh

Smoothing

Optimisation

ShrinkWrap created a watertight mesh around NURBS geometry, SubD objects, meshes, point clouds or collections of points. It was particularly useful for scan data, imperfect meshes, 3D printing and reverse-engineering work because mixed or incomplete source material could be converted into a coherent mesh. Smoothing and optimisation controls allowed the result to be refined.

Rhino 8 also added and extended tools for UV mapping, rendering, drafting, meshes, SubD, Grasshopper and interoperability. Taken together, the release addressed both major modelling tasks and the repeated operations that shape everyday use.

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.