Layer Control in Layouts & Thumbnail Update



Layers that are off in model space cannot be turned on in the Layout Layer Manager. Therefore, all model layers need to be on in order for us to control layers in the Layout & Detail Layer Managers. Does this sound correct?

Ideally we would like model layer control to be independent from layout layer control.

(John Brock) #6

THat’s not how Rhino works.
The layer visibility is hierarchical as I described in my previous post.
Model layers are the main control
Layout and detail layer settings are additional controls but do not override the Model layers settings.


Hi John,

Your fast responses are amazing! Thank you!

Would this type of independent layer control ever become a feature? It would be great for architecture firms working back and forth between the model and layouts. Or maybe the hierarchical system work better for most Rhino users?

Thank you

(John Brock) #8

I don’t think so.
The system we have now is the result of working with other Rhino users.
I don’t think a major change like that would be a welcome change.

Instead, have a look at using the Layer State Manager.
Then you can name, save, and restore different combinations of layer settings.


Again, thanks for the replies. I completely understand the hierarchal structure you described in your previous post. I guess what I was getting at is that with the model layer manager as the main control, the layout layer manager is effectively rendered useless (as witnessed by not being able to control layers in the layout). In any setting, architectural or otherwise, I fail to see how this is not a concern/issue. Perhaps there are examples out there, I’ll do some research but would like to open up the conversation if at all possible.

The revisions discussed above could act as and replace the need for layer state manager settings in layout. The conflation of those two seems redundant.



From a work flow standpoint- we’re in a position where we need to turn on all of the model layers when we switch to layouts, then when we return to model space, turn off all of the layers we just turned on. If these settings were independent of one another, substantial amounts of time could be saved. Appreciate the time & consideration.

(John Brock) #11

As long as you have a stable set of layers, the Layer State Manager can be used for this.


We’ll give that a shot - I know a few colleagues have had issues (bugs) with the Layer State Manager in the past. Holistically, I think there is significant value to having the layer controls (model vs. layout) independent of one another in any/all applications. If there are instances in which the opposite proves to be true, please let us know. We really enjoy the program and appreciate all of the work you and your team puts into each update, the above is just our intersection with Rhino and ideas for improvement. Regards,

(John Brock) #13

That’s what this forum is for. A public discussion of how things work, why, and how than may be improved.
I’m a little surprised no one else has chimed in either way yet, but it is a Summertime Friday.


Well, I could imagine a layer manager that showed a layer state in model space and a different layer state in layout space. That is to say that the two coexist in the same panel and come up automatically depending on which space you are currently in - for example if you were on a layout page, but were to to double click on a detail, you are actually going back into model space, so the model space layer manager would come up…

The two managers would be interrelated of course, the same layers would have to exist in both, so editing (as in adding/deleting/characteristics/sublayering) would be global. But the Model space panel would control model space visibility and the Layout space panel would globally control layout visibility. The various Hide/Show in detail commands would still need to exist, but might be interesting to have that show up in the layout panel when a particular detail is active - as in some symbol that indicates “this layer is hidden in this detail”.

You would also need two layer state managers for saving and restoring layer states, of course.


(Dan Belcher) #15

This behavior should be somewhat better in the latest RhinoWIP (5E41w). Please give it a try…hopefully those thumbnails update when the layout layer change.


It’s not quite there yet. The thumbnails all show it correctly when switching a layer off, but only the current page shows it coming back on.


(Dan Belcher) #17

I see what you mean. I can see where toggling the visibility of a model layer that is shared across many layouts and not seeing the thumbnail update is rather jarring.

Looking at MR-2776 here (sorry, it was not visible to the public until just now; an oversight on my part).

It looks like this behavior is intentional judging from this comment by @marlin.

Actually, I take that back: it sounds like the previous behavior was intentional. Marlin, should I reopen this bug? I believe I’m able to reproduce what @maxz is reporting.

(Marlin Prowell) #19

@maxz I explicitly set up both the current behavior and the previous behavior just for you. Really. Thumbnails do eventually get updated, just not immediately. I limit how often thumbnails are updated to improve overall performance.

Remember this thread? Layouts slow down drafting

In the modeling window there typically are four viewports that get updated with every change. In the layout window, you can often have 3 or four viewports per page, so this doubles the number of viewports that are updated with every change.

For you, going from updating 4 modeling viewports to updating 8 viewports (4 modeling, 4 layout) slowed things down. Back then, no layout thumbnail was updated immediately.

Consider that every thumbnail is another three or four viewports, so constantly updating all the thumbnails will require updating 10 to 20 to 30 viewports, depending on the number of layout pages (and thus thumbnails) you have. Updating all the thumbnails all the time would likely make modeling on your older Mac pretty frustrating.


@Marlin: I do remember that thread and I really appreciate that you went through that trouble just to help me, but I am not the one that started this thread, @charliev mentioned it. I merely reported my findings on @dan’s request. Since version 5.3 layouts are not opened automatically on startup, which also helps a lot. I am happy, thank you.



I agree. When each layout is supposed to show a separate part, or a selection of parts in an assembly, it would be very handy if the layer settings for each layout stays the same while working on the model. I can’t really see any point having the layout layer settings at all if they get overridden the moment the model is edited. Maybe I am not using the layouts as it is ment to?


Yes, I fully agree with that! Layer visibility should be completely separated between model and layout states.

Seems like they are considering the change, as you can see here

(Be) #24

First off, I would also love to have the ability to work with global/model layers and layout layers independently. That would ease the process when having multiple plan-drawings with lots of info on top of each other, and wanting to sift through different layers in the layout.

Second, I have a problem concerning the “Layout and detail information”. My detail view in layouts is constantly showing all layers, even when disabling different layers in the “layout and detail information” tab. The only action that effects the look of the layout is when i toggle the layer where the detail view is located - then the detail view disappears. But I am unable to change the visibility of the different layers from the “Layout and detail information” tab. Any ideas?

I hope this makes sense.


(Be) #25

Ah, I just realised that you need to have the detail view active for the “layout and detail information” layers to have any effect.
Sorry for the inconvenience.


I’m sorry with who don’t think so, but to me don’t have the possibility to hidden layers in model space independently from the layout space is merely an idiot thing. It means a lot more work. I think it is a background from the “Microsoft window style”: if you can do one thing with one click… do it with ten clicks. That’s my opinion. Roy