Alphabetizing layers

I’m just going to post a few problems I’ve been having - I’m generally a Rhino 4 for PC person so it’s possible there are simple solutions I’ve been missing - but otherwise I guess this is a wishlist for the next release.

Question 1: is it possible to sort layers and viewports in Rhino 5 OSX? When I left- or right-click on e.g., the “Name” bar at the top nothing happens. I’ve resorted to sorting them manually, which is as much fun as it sounds. If I’m missing something obvious, happy to be corrected!

1 Like

+1 for muduri’s suggestion.

A few other “Layers” questions/suggestions:

  1. I realize one can have sublayers, which is nice. Is there any way to make “layer sets” that I’m missing? If not, this capability would be supremely delicious. One could keep their layers organized, but toggle on/off desired layers for different desired sets when needed. Among many benefits, this would be especially useful for renderings if one has backgrounds, lights, etc to turn on/off. This would beat the hunt-n-peck needed to turn on/off layer displays that I find myself spending a lot of time doing.

  2. In addition, is there any method to automatically turn off the active layer when selecting another layer instead of having to click twice (once to select new layer, then go back and click the former layer to turn off? This is a serious time waster and can easily get one into trouble. I think here of a modifier key held down when selecting a new layer.

  3. And while I’m on a roll (sorry!)… Unlocking a locked layer simply because one (often accidentally) selects it is a REALLY, REALLY BAD IDEA, causing idiots like me to lose work due to unnoticed edits to a layer one thinks is locked. Can this automatic “feature” be turned off? A locked layer should ALWAYS require a specific unlock selection to prevent random acts of accidental stupidity. :smile:


No, this is not implemented. Logged as a bug.

I don’t understand your question.

When you lock or hide a layer that has sublayers, all the sublayers are also locked or hidden. Does this answer what you want?

No, this is not implemented.

Actually, this is a VERY GOOD IDEA. First, let’s define a few terms. “Selecting a layer” means clicking and highlighting a row in the layer table. “Making a layer the current layer” means clicking the radio button in the second column in the layer table. Doing the latter makes this layer the target for all new objects, so of course the layer needs to be editable. The radio button is deliberately a much smaller target to click than clicking to select the row. If you click the radio button, your intent is clearly to change the current layer.

You just mentioned in point 2 that you wanted to eliminate the second of two clicks. You want this because you like to work with locked layers, but not everybody does this. Now in point 3 you want to force two clicks where one click is sufficient to signify the intent of changing the current layer. ???

You like to work with most of your layers locked to prevent accidental changes. How about this:
Keep all your layers locked except one working layer where you create all your new geometry. When you are satisfied with the new objects, select them all (perhaps using Select objects in layer in the context menu). Select the layer you want to contain the new objects by highlighting the layer. Do not make this layer the current layer; just select it. This layer stays locked. Now choose Move objects to this layer in the context menu, and the objects are moved to the selected layer, and the selected layer was never unlocked.

Thanks guys for the update on where it stands and for adding the other layer suggestions. Marlin, sorry, yes, I should clarify the cryptic “sorting viewports” clause - I was just hoping there would be a way to alphabetize the viewports in the “Views” palette. Often the cameras will be labeled by render order and it’d be great to change the order they display in, by dragging or by sorting alphabetically. Thanks!

Unfortunately, no. I’m referring to a concept that would be similar to “Named Views”.

I’m aware of sublayers, and while helpful for other tasks, sublayers do not address the powerful potentials inherent in what I’m calling “layers sets”—which, I believe don’t exist currently, but would be very useful for many.

For example, let’s use the original Baskin Robbin’s “31 flavors” of ice cream. If one were to model a scoop of ice cream for every flavor, you’d have 31 layers named for each flavor. For simplicity, you model only one scoop, but copy it to each flavor layer, with a different color and texture assigned.

To create a second scoop, you would simply copy it to a new flavor layer positioned one scoop higher to net a total of 62 different layers. Repeat same process for a third scoop and you would get 93 layers. Now add a layer for each container: cup, cake cone, sugar cone, and waffle cone to create four more layers for a total of 97.

To show Today’s Feature (which is any variation), sublayers alone will not easily enable this. However, if one were able to have “layer sets”, you could pick the layers for the desired container and the layers for desired scoops and call this “layer set” something like Monday, January. Another layer set for Tuesday, January, etc.

Now, extend this logic to other types of projects where various layers serve different functions, but relate to the project. When presenting information to clients, fabricators, and consultants, one often needs to show very different layers to different parties. A “layer set” would easily allow one to define the desired layers for different concerns only one time, then easily turn them on and off, rather than hunting and pecking on/off states each time one needed the relevant information.

Does this make sense?


Too bad. I think this is an opportunity to improve existing functionality in Rhino since reduced clicking and mousing improves productivity.

Back to the Baskin Robbins example: with 97 layers, dealing with layers at opposite ends of the layer structure currently requires a lot of scrolling to simply Make Active a layer, while turning off the View of the prior layer.

While Adobe is usually not my favorite exemplar, they have done a fairly good job with layers in Illustrator. In a file with multiple layers, when one holds down the option key and clicks twice on new layer’s View checkbox, that one layer can very quickly be viewed alone. (Where Adobe falls short is that it fails to allow you to also Make Active that new layer, requiring another click. Definite area of improvement for them as well.)


Windows has its LaterStateManager which addresses some of this - creating sets of on/off/locked layers which can be saved liked named views - but it is not yet implemented on Mac. It’s actually part of a plug-in which is automatically installed with Windows Rhino.


Apologies for some vagueness on my end, Marlin. Because of this, you’ve understandably drawn a few inaccurate conclusions.

Terminology Used Here:
Select(ed): Blue bar for entire layer. Resulting from clicking on Layer Name
Activate(d): Radio button. Turns on View and Unlocks (and the unlocking is my concern). Becomes active layer for new objects.
View: Light bulb icon. Toggle on/off the ability to view state.
Lock: Lock icon. Toggle on/off the ability to edit state.

To clarify a little, I actually do not “like to work with most of [my] layers locked” In fact, I rarely use locked layers, which is why a locked layer’s ability to be modified (if Activated) came as a recent surprise to me when some consultant information was placed on a locked layer, then accidentally Activated, when I simply wanted to View it.

As we know, Rhino uses four different editing modes. In Adobe Illustrator, they use three—with Select and Activate being the same action. In Illustrator, a chief difference—which I still believe is better since accidents can not easily happen—is that the Lock needs to manually be toggled off, even if Selected/Activated. If one tries to draw on a locked layer, the tool icon has a slash through it and nothing happens. Unlock the layer, and the tool works.

What I believe would be improvements to consider for Rhino:

A) If one held down a modifier (option?) while Selecting a layer, the View state would also turn on if it were off. Possibly, it could even toggle on/off by Option+Selecting the layer name.

B) For the reasons stated above, Unlocking should always require a specific toggle, even if Activated. After all the radio button and the light bulb are very close to each other and easy to flub in the heat of battle.

I’m fine if we differ on this. Thoughts from others welcomed, as well. And thanks for the thoughtful workflow suggestions.


The correct terminology is the “current” layer. The current layer is the one that new geometry gets created on and therefore always needs to be unlocked. So when you make a layer current, it unlocks it if it’s locked.

All operations in the layer dialog go into the undo stack, so if you “flub”, just hit undo…


Yup, Mitch, you’re right. Feel free to substitute “Make Current” for “Activate” in my previous post—the intent is the same.

And yes, I understand that the Current layer needs to be unlocked to create geometry. To be clear, I disagree that it should automatically be unlocked when it is Made Current. This is because (a) it’s too easy for a layer to be “Made Current” accidentally, and (b) the consequences of accidentally modifying a locked layer may not be noticed until much work has been done.

Sure, accidental changes to a locked layer may be recovered (if the undo stack is not exhausted); however, all subsequent work may very well be lost, or difficult to recover meaningfully.

Thus, this is not a “How do I do this?” question; but rather, “Might this be an improvement?”.


That much I understand. I am simply questioning the “improvement” part.

The result of the improvement will be to make the act of setting a layer ready to draw into two clicks instead of one, or at least the requirement to stop and check to see if the layer you’re making current is locked.

Then, if the current layer can be locked, I’m sure there will be lots posts here complaining “When I try to draw stuff nothing happens…” And if you put up something like the tool slash thing you mentioned, people are going to complain "Why am I getting this and why can’t I draw stuff?.

Sure, I hate “flubbing” stuff, typically with me it’s when I want to select all with Ctrl+A and I hit the S key instead, forcing a save of a big file and making me wait a half a minute before I can continue doing anything… But I still prefer that to having a dialog come up every time with “Are you sure you want to save?” and having to hit OK. In wanting to prevent all possible errors, you can destroy a smooth workflow by interrupting the process with checks and questions…

Anyway, that’s just my 2¢, take it for what it’s worth… ***


Good discussion, Mitch. As you’ve likely concluded from my other posts, like you, I’m 100% in favor of improving workflows by reducing mousing, clicking, and eliminating “nags” from dialog popups. Elegance above all, I say!

Regarding Locking/Unlocking layers—and only for this one point—I will ardently support more caution. I maintain that one Locks layers by clicking on the Lock and one should ONLY be able to Unlock them by clicking on the Lock again. Not only is this behavior analogous to real life behavior (which makes it be more intuitive), there is one very good reason that manual unlocking is likely in everyone’s best interest, McNeel’s included —LEGAL LIABILITY!!!

For a decade, I was a partner of an architectural firm. If I knew that any of my employees (which also included interns) could easily and accidentally unlock and modify a locked layer that contained information that was to be used solely as a reference, I would be VERY reluctant to use Rhino in a meaningful way. Locking a layer is meant to be sacred and is often done for very important reasons when coordinating information among many parties. GREAT deliberation should be exercised in unlocking sacred information due to the potential for very serious errors that could become very expensive.

I’m not trying to be alarmist, but pragmatic. Since Rhino is a big tent, perhaps a good middle ground to consider is for default behavior to be as I’m describing it, but advanced users may choose to use the existing method you favor, where layers unlock when they’re Made Current?


Well, that’s your point of view…

Mine is that locking layers is just another tool like showing/hiding/grouping objects etc. If you need the kind of absolute security you’re talking about for your data, I think you will need far more than just security in locking and unlocking layers. Maybe something more like worksessions plus strict access control is what you need, where people can access files but to look at them and even copy data from them, but not modify the original data…


Also a good idea, Mitch!


To my surprise (and delight), I discovered today that one can easily rearrange the columns (by click-dragging) in the Layers. While you still unlock layers when Make Active is selected, this might be of interest to some.

Nice touch RM&A!


1 Like

You know, apropos of this conversation it does occur to me that in 4, the Locked icon was grey, and Unlocked was yellow. In 5 they’re subtly different shades of gold, which frequently means hunting through your sublayers to find out why your slab didn’t export - or possibly finding that the intern deleted the HVAC system from the contractor, ha. More obvious difference would definitely get a thumbs-up from me.

isn’t that an apple lock icon?
(like the one you’d see in a get info window)
or is that how it looks in windows rhino too?

[cant check for myself… on a phone]

Here are the Rhino windows symbols Jeff

ah. yeah, i guess i can see how it would be easier to see locked vs. unlocked in a long list of layers…

idk, i personally don’t see a problem with the current layer lock icon but i can understand that others might
(a typical drawing of mine has around 20 layers at the most… i might feel different about it if i was a mega layer_er)

I notice it’s still not possible to sort layers by name. (Using 5A855.)