Rhino Default File Settings

Hi guys, as you may know Rhino has tons of plugns, and stuff to add to it. I noticed that when you add a new button, or plugin or w/e to your current opened Rhino, it does not stick to the default one, but instead it just sticks to that file. Moreover, when I open others people files, on my pc, my add ons do no appear.

Recently I personalized Rhino while working on a file, these just stuck to the file I was working with, but did not transfer to all new Rhinos. I was forced to do all changes again but in the default “untitled” Rhino window.

The question: How do I make changes (and by that I mean, new buttons, plugs in installations, etc) permanent in all Rhino files and new files. I want to have them there everytime I open Rhino.

Thanks in advance, Shynn


Mate I’m no expert but I have administered other CAD products before just not rhino. Its a good question but I’ll offer what I used to do with other cad software. Normally SW settings/configurations are considered document based or software based some changeable and other hard coded.

What I did was create custom company specific document templates to capture every setting document related to these and re-path the cad software to these templates for creating new documents from scratch. If I wanted the UI of the software to be customized from default normally that required configuration seed files to be deployed out to specific users depending on their role.

I don’t know if that’s the same in Rhino but it can’t be far away I think.


At least you understood me perfectly :slight_smile:

Smart thing you did there with CAD

Hi Shynn - if new buttons and added/loaded plug-ins are not showing up after closing and reopening Rhino, something is amiss - make sure you only have one Rhino instance running, for now, to make sure - either reboot or check TaskManager > Processes to make sure there are no extra open but not visible Rhinos - it can happen. Then open Rhino and load the plug-ins and make changes to the toolbar file (e.g. add or edit buttons) . Close and reopen Rhino - did the changes stick?

If not, try closing Rhino and then from the right click menu of the icon that you use to launch Rhino, choose Run As Administrator - make the changes, close Rhino and reopen normally - not as Admin… is that any better?


In my experience, adding buttons is a totally random process where you may or may not get your button the next time you start Rhino, depending on the phase of the moon and the relative humidity on Mars.

For example, recently we had a case where a button had lost its image. No matter how we tried to re-assign the image to the button, it did not show up the next time Rhino started. IMHO toolbars and RUI files are terminally broken.

Note that “buttons” and plug-ins are very different and need to be treated as such. Buttons are stored in the .rui file, they should be only modified with one Rhino instance open at a time, then you can save the workspace as shown below, and close and re-open Rhino for good measure. If you modify your personal workspace, it is highly recommended you save it under a different name.


Plug-ins are global. Once they are loaded, they should be active for all future instances of Rhino that you open. You cannot have a plug-in active in one currently-running instance and not another. I would also load plug-ins with only one Rhino instance open, or if possible via an .rhi, .msi or.exe, when Rhino is completely closed.

If you are having trouble saving your changes in your workspace, perhaps you don’t have write permissions for the folder where they are stored…


In addition to all of the above suggestions, you can open a new instance of Rhino, make sure all of your buttons are added, and any work space modifications are in place, and then “Save As Template”. You’ll be directed to the Template file and asked to give this template a name, and you’ll be able to set this template as the default opening scheme by checking the box at the bottom of the template file that asks if you want Rhino to open with this template every time. Or, of course, you might need/want several different templates available, depending on the specifications of your various models.

Best regards,

Unfortunately, this will not help with toolbar buttons, they are not stored in Template files. They are only stored in .rui (Rhino User Interface) files. The default location for .rui files for Rhino is



Thanks, Mitch!

@menno ditto that.

I hear the frustration in that, and mine is similar. Toolbars have been a mess since V3 or so, and although V5 stabilized some of the issues, the whole system is like a house of cards, and certain events cause it to come tumbling down. Some of the events are predictable and some are not. For example every time I edit a button - maybe just to update a script or macro - the next time I open Rhino I can be sure that the whole workspace will be messed up, toolbars becoming undocked, etc. However sometimes I just open Rhino - not having edited anything previously - and all the toolbars are gone… (you get “root element is missing”, whatever that means).

The current WIP version is the worst ever for me, it blows up more or less every time I start it. My own workspace isn’t all that complicated either.

Where the fault lies is hard to know. I think simply that as in my “house of cards” analogy above, in putting in all the flexibility that toolbars have today (in Windows Rhino), the system has simply gotten too complex to successfully manage all the possible interactions. (Note in passing that Mac Rhino does not have these problems, but the customizability of the workspace is far more limited… )

One of the primary causes of this is that the Windows Rhino toolbars (macros, images, organization of the bars themselves) are in the rui file, but the locations of where they are located on-screen and which are open are not - that info is in the registry. Correlating the two seems fail under certain conditions.

Another is simply that buttons can be any size (horizontally), toolbars can be docked anywhere, etc. etc. The possible combinations are infinite, and I am guessing that managing this complexity simply fails under certain circumstances. Can it be made to work reliably? I’d like to be optimistic about it, but I’m not unfortunately - based on the fact that if it could have been fixed, it probably would have been a long time ago.

I guess the main thing that saves us is that, aside from hiding and showing standard toolbars, very few people actually customize their workspaces substantially.


1 Like

@Helvetosaur That explains a bit better why every time I open Rhino I have to toggle closed two plugin tool bars that I never use closed and move another two. Pascal tried to help me some time ago in this thread.


In the end I have just come to accept this as the one flaw that annoys me in an otherwise very useful tool and have moved on.

Would be nice to see it fixed, but from the sounds of what you are saying about the WIP we are stuck with this for a while.

This is actually the plug-in manufacturer’s fault and not Rhino’s. It’s how they programmed their plug-in. I am always surprised at certain plug-in manufacturers who either egocentrically or ignorantly seem to believe that theirs is the only plug-in that a user will ever have loaded, and that using their plug-in is the only thing the user will ever do with Rhino.


@Helvetosaur Yes we sort of came to the conclusion in that thread after @andy helped out that it was Rhino`s fault when it forgot where I had placed open panels but the plugins fault for force loading/opening panels on startup.