Rhino BETA Feature: New User Interface

Rhino BETA has a newly redesigned user interface. It is cleaner, more consistent, and friendlier for newcomers, while keeping every bit of the speed and control that experienced users rely on. Here’s a quick tour of what’s new.

1. One UI, Both Platforms

Rhino 9 introduces a single, unified interface across Windows and macOS. Whether you switch machines, collaborate across platforms, or teach in a mixed lab, the layout, panels, and tools now look and behave the same everywhere. Learn it once, and you know it on both.

Prefer the Classic Look? It’s Still There

Change is optional. If you’d rather keep the layout you’re used to, switch easily from the menu:

  • Window > Window Layouts > Classic (Windows)
  • Window > Window Layouts > Classic (Mac)

… at any time, on either platform.

2. Concept Display Mode

Concept is a new native display mode tailored for architects and designers who want to present their 3D models with a clean, early-design stage aesthetic in Rhino. Learn more about the Rhino BETA Feature: Concept Display Mode.

3. A Friendlier, Powerful Command Line

The command line blends the best features from the the classic Windows and Mac command lines. From Windows, a space-saving, horizontal layout at the top of the screen. From Mac, Buttons, drop-downs, and toggles - restyled to look like the rest of the controls on the Rhino screen. We’ve kept the power-user friendly typing that has always been a core part of the Rhino command line.

4. New Toolbar Colors

Toolbars now use a refreshed color palette that groups related tools and makes icons easier to scan. You can read more about the new colors and see community discussion in this thread: New icons in V9 WIP.

This new visual language has been carried over to the menus as well - The same updated icons have been added to the Rhino Menus for more consistency.

5. More Panels By Default

Quicker access to the tools you need most - Rhino now ships with Rendering and Layouts panels turned on.

6. Refreshed OSnap Panel Icons

The Object Snap panel has new icons that are clearer and easier to read at a glance, making it quicker to spot the snap you need.

7. Your Settings Come With You

Upgrading is painless. The new Transfer Settings feature brings your window layouts, shortcuts, aliases, plug-ins, custom RUIs, and more, over from Rhino 8 and earlier. Just run OptionsMigrate and your preferences and customizations carry over, cross-platform. Full details here: Rhino BETA Feature: Transfer Settings.


We’d love to hear what you think. Try the new interface, and let us know how it fits your workflow: your feedback directly shapes where Rhino 9 goes next.

Thank you for your efforts. Please also fix the Full Screen issues listed in the issue tracker so that the user interface is free of problems and provides a smooth experience.

Great to see the consistency!

Hopefully this isn’t hijacking but any chance as part of the UI review darkmode grasshopper can be looked at? The largely black icons on a basically black background is a lil too dark for me! (I note, you can see the full names when you click the bottom of the section, but I’m used to being able to identify components by icon!

The new UI looks much better and more consistent. Nice work!

I’ve been reorganizing my Rhino interface lately, and while doing that I noticed something about the way some of the toolbars are organized that I don’t quite understand.

Looking at Mesh Tools, for example, there are several generic operations mixed together with mesh-specific tools. Some of them are Transform operations, while others are related to Groups.

But these operations are not mesh-specific. Transform operations already have their own general-purpose toolset and can be used with different types of geometry.

This becomes especially noticeable when the Transform toolbar is permanently visible elsewhere in the interface: some of the buttons in Mesh Tools simply duplicate functionality that is already available elsewhere.

I noticed the same organization in Rhino 8, and Rhino 9 seems to continue this approach.

So I’m curious: what is the intended organization principle behind these geometry-specific toolbars?

Wouldn’t it be clearer if generic operations were also available in dedicated general-purpose toolbars? This could provide more flexibility while still preserving the current organization.

For example, generic and frequently used commands such as Cancel, Trim, Split and Join could form a small Basic Tools toolbar that can remain permanently accessible, regardless of the type of geometry being edited. Similarly, the Group-related commands could form a dedicated Group Tools toolbar.

I’m not suggesting removing commands or reducing functionality. Quite the opposite — I like having commands visible and easy to discover. The existing combined toolbars could remain available for users who prefer the traditional layout, while dedicated, non-duplicated toolbars could provide a cleaner alternative for users who want to organize their interface differently. My point is about avoiding unnecessary duplication and making the organization easier to understand.

At first glance Rhino can appear to have an enormous number of tools, but while reorganizing the interface I realized that part of that apparent complexity comes simply from the same general-purpose operations being exposed repeatedly inside different geometry-specific toolbars.

I think having the option of a clearer separation between geometry-specific tools and general-purpose operations could make the interface easier to learn and customize, without actually hiding or removing anything.

I’ve attached screenshots from Rhino 8 and Rhino 9 to illustrate what I mean.

A related idea: optional automatic contextual flyouts

While looking more closely at the existing toolbars, I realized that another source of apparent complexity is that many separate commands represent different construction methods within the same tool family.

Circle is a simple example. Rhino provides several ways of creating a circle, but from the user’s point of view these are essentially different methods of performing the same operation.

What if a flyout could optionally open automatically when its main tool is clicked?

Clicking Circle, for example, would still immediately start the default Circle command — no additional click would be required — but the Circle flyout would also open automatically, making the other construction methods immediately visible.

The same principle could apply to Arc, Curve, Rectangle, Ellipse, Line, and other tool families.

This could be an optional behavior, so nothing would need to be removed and the existing manual flyout workflow could remain exactly as it is.

I think this could make the interface both simpler and more discoverable. Fewer icons would need to be permanently exposed, while less frequently used methods would become visible automatically whenever their tool family is used.

And I don’t think this is only useful for new users. Even experienced users tend to forget tools or construction methods they haven’t used for some time when those methods remain hidden inside flyouts.

In other words, instead of simplifying the interface by hiding functionality, Rhino could show the relevant functionality at the moment it becomes relevant.

Another update to the Rhino BETA UI - Icons have been added to the menus!

This will help keep a consistent visual language between the toolbars and menus, and should boost visual recognition, speeding up workflows when compared to the previous text-only menus.