Need some basic Rhino 5 info

I’ve looked at the help and various McNeel V5 sources on the web and come up short.

I think it would be helpful if the following information was in the help and called out in the table of contents. Also in some key spots on the web - also clearly indexed:

What files the install puts on the user’s computer. (at least the various types)

Where it puts them.

What the command line startup options are.

It’s pretty basic, even if it’s not often used, but important when it’s needed.

Command-line startup options are in the help in the topic for the Open command. Tell me what you searched for when you were looking for this.

As for the list of files, I’ll consult with the developers about this one.

Well, there you go Margaret. It never occurred to me to look under Open, as I just assumed that would talk about opening .3dm files in Rhino - not opening Rhino itself. You do realize I am talking here about the Windows command line or it’s analog in the desktop Rhino icon’s properties, not Rhino’s own command line, don’t you? I may not have been real clear on that. …Now that I’ve checked the help under Open, I realize that you did indeed misunderstand me.

As to what I looked for: in the help I just scanned down the contents, clicking to expand any topic that remotely looked like it would have anything to do with my search. Similarly with the wiki and FAQs.

A topic like “Starting Rhino” or “Opening Rhino” would be great.

I know that your focus in thinking about the help is on how to do things in Rhino - but you seem to have completely overlooked the fact that in order to do anything at all in Rhino, you need to be able to start it up. I’m teasing you here, of course, but there are some startup options for Rhino and I think they should be enumerated under a heading like I’ve suggested. I know the “safe mode” is described elsewhere in the help, but I think the topic heading I’ve suggested would serve as a useful conceptual “master node” in the help index - what to do before you do anything else. I also think some more details about the safe mode could be included about whether plugins can be loaded by the user after opening in safe mode with no plugins, whether it’s just user plugins that are skipped, etc, etc.

There are folks who like to “think before doing”, or in other words “read the help before trying and erring”, so more verbiage about what the safe mode is for, what it does and what the user can do with it couldn’t hurt.

Also - are there any other startup options that users might find useful? The proposed topic would provide a good placeholder for any new ones that may come up, too. For instance, Dale Fugier suggested it would be possible to allow each user to have multiple named start up configurations. I don’t know whether he put it on the wish list, though.

As to the file list: it probably would be most useful if the first sort was on the directories that Rhino puts files in (all of them, including Windows system directories), with a description of the types of files that each directory is intended to hold. Then a list of the specific Rhino-installed files in each. The file list would serve as a customer reference checklist of what should be in the directory to see if any are missing, as well as an indication of what shouldn’t if he’s trying to see if any rogue files have shown up. The directory purpose description should include suggestions about what types of user files could be added to each, or McNeel’s recommendation that no user files be placed in a specific directory. This section should probably mention in general what kind of information is kept in the registry in order to answer the user’s curiosity about “how do it know” about all the things he used the last time and the way he’s set up the options. Certainly no need to get very detailed here, except to list the categories of info that go in the register.

That’s my story and I’m sticking to it.

Already exists… Look at “Schemes”… although no real mention in the Help about what they are or how to set these up - they are mentioned on the “Open” page in the Help is all.

On the same Open page in the Help, there is a listing of the startup switches, although I don’t know it it is the complete list.


I should also say that since Schemes were introduced in V3, I have wished for them to be made more user-friendly and the UI integrated into Rhino - wish that has gone unanswered until now.

I think it would be useful to have user interface in Rhino to take you to the various folders that store information you may need to find:

toolbars, template files, plug-ins, etc.

But having an enumerated list of all the directories and files used by Rhino seems like a chore to maintain (we change the file system all the time, sometimes with service releases), and for almost zero gain.

Let’s pretend you knew what every file was that installed. What are you going to do with that information? If it’s not installed properly, reinstall or repair - you’re not going to fix it by hand anyway.

I’m not completely sure what you mean by a user interface, but it sounds like there’s some potential there.

There’s also the McNeel-supplied “starter kit” materials, textures, environment maps, etc.

I must admit my assumption was that the list would be automatically generated either at release time and supplied in the install file, or by the installation process itself. Maybe it already is at install time and is in a log file. Or easily could be. For the user an install-time list would make the most sense. Perhaps your “user interface” would just read the log file and present it in an easy to read format.

I hesitate to admit to “almost zero gain”, as it does have some housekeeping value as I suggested: is all the stuff there, and only the stuff that belongs? I agree it certainly wouldn’t be used every day.

However, as you plainly state: “we change the file system all the time, sometimes with service releases” and it sure would be nice for the users to have some easy way to keep up. For example, I can’t find the environment maps. I’ve looked everywhere. :wink:

C:\Users\user\AppData\Roaming\McNeel\Rhinoceros\5.0\Localization\en-US\Environment Maps

Most of the UI stuff is in



Darned if it isn’t just as you said.

I guess the Open topic doesn’t look in a quick scan like it’s got anything to do with what I was looking for. And to boot, the Open topic was certainly not the first (or 23rd) thing that came to mind when I went looking for help on Rhino startup.

Now that you’ve pointed it out to me the “Schemes” concept is coming back. I’d forgotten completely about it, though it did get some discussion when it was introduced. Up 'til now I’ve had no use for it.

I see from the description under “Open” that a scheme will save “All the settings in the Rhino options pages…” with a list of examples. The list doesn’t specifically mention the plugin load settings, although they are certainly part of “All the settings in the Rhino Options pages”. Can anyone confirm that these are included, or is it “left as an exercise for the student”? Does the use of the word “All” really mean “absolutely everything” and not just “the stuff we thought was important”?

Thanks very much Mitch. Once again your remarkable expertise has come to the rescue! I certainly agree that usability improvements could be made, and certainly some major documentation improvements too.

Now that I’ve been educated by Mitch as to what is contained in the “Open” help, I have some comments:

I found “Open” by clicking the “O’s” under Commands in the help.

In my mind, starting Rhino is not a “Rhino Command”, it is a “Windows Command” - literally if Rhino is started from the Windows command line (theoretically possible even if not usually done) and figuratively if started from the Start button or a desktop icon. That’s why I think it should have it’s own major topic in the Contents right after “What do you want to do?” and before “Commands”. “Commands” could even be relabeled “Rhino Commands”. Or maybe it should actually go right BEFORE “What do you want to do?” since “What do you want to do” is actually specific to working in Rhino.

I could certainly see cross-referencing between “Rhino startup commands” and “Rhino Commands”, but these are really two separate topics and need their own entries in the Contents. I haven’t played with what kind of search terms might get me to what is now “Open”, but clearly some thought needs to be given to that as well. I’m not so sure that “Schemes” would be much use to someone unfamiliar with that name and searching for the concept, but certainly needs to be there for the person who is, but looking for details.

Hi, AIW,

Thanks for the response. I will add some stuff to the index based on your comments.

~M Becker

Thanks, Margaret.

Thanks, Mitch - right where you said they were. I sure can’t see the logic behind burying the maps so deep. Why not up in …/Rhinoceros/5.0 with the rest of the stuff? @brian

I finally had a chance to read your Wiki article on “Schemes”. Thanks for writing it. (Looks like it’s ripe for inclusion of references to V5.0, even though I suspect the actual info is still good). Too bad about initial plugin loading choices not being customizable with this feature. Even though it does seem like the most logical spot for it. And even though it seems logical that initial plugin loading would be one of the things that a lot of users would use it for if they could. @brian

The logic is that is is USER based, so if your partner log in on the same machine then you’ll both have custom setups. This is important on situations like for schools where there are “labs” with computers and where the users swap seats, so their setup follows them around.

Rhino is just using Windows default setup for organizing the data. I do agree that it is not stored in a logical place for a new user.

It would also be great if it was possible to save all these settings to say Dropbox (or skydrive etc) and then load them from Dropbox too. I thing this should be implemented in V6 since more and more stuff is becoming “cloud” based. Having a custom plugin folder on dropbox would be great.

Because some users have requested for all user-editable information to be in a user-specific location that moves from computer to computer with their roaming profile. The %appdata% location is just such a place.

hmm… i’m starting to think the ‘just get in there and go for it’ attitude is actually the smarter option

i kid… i kid

Sure, I can get the appdata concept, but why \Localization\en-US\ for environment maps? Why would environment maps have anything to do with localization?

What with putting stuff in directories that might make perfect sense when considering the big picture, but not making much sense to individual users with their individual narrow backgrounds, I’m beginning to see your reasoning behind a “UI” for showing it all.

I think the issue of how far Windows userids “roam” is determined by Windows design. No doubt as Windows cloud capabilities develop, this kind of functionality might become available. I think that in Windows 7 and 8 user info will range as far as the organization’s private network does. I’m not so sure that it would ever become a good idea to let it roam to public cloud services.

Rhino ships in 11 languages and supports having multiple languages installed at once.

I don’t know about you, but if all the EMap files were named with Korean names, I would not find it useful. The converse applied to our Korean customers. Thus, EMaps fall into the cstegory of a localized resource. 

Brian Gillespie