Adding an additional column to the Layer panel with a global layer visibility has been mentioned internally before. The initial concern was additional screen real-estate and the goal was consolidation of the new control.
At this point, we feel it is worth turning on this globally column for you to “test drive” in the WIP.
It will definitely be more discoverable, avoid the RMB that is not always obvious, and those that don’t want it can simply turn the column off go forward with the use the RMB for accessing the global control “Everything On” and Everything Off".
I logged RH-72482 Turn-on-Column-for-Global-Visibility-in-the-Layers-Panel.
We will let you know where there is something to test.
The problem with this suggestion is that it’s a completely non-sensical column for most users that never use layouts in Rhino. Fundamentally, having an “off everywhere” and “only off here” column that does exactly the same thing most of the time for most people is a net loss for us.
That said, I also think that hiding functionality behind a right-click doesn’t help people that need it.
We already have too many controls on the screen in Rhino. So, I guess that means we might as well add a ton more, because it’s already overwhelming. But the other argument is that we should really focus to make Rhino more usable without being so complicated.
All this is to say, I think adding a column is the cheap, easy, and wrong answer. I wonder if there’s another way to:
Thanks for the reply!
I was expecting this kind of argumentation… =}
How about this: this omious icon is already there in model space, but greyed out:
Just make it functional, and set the default to “view model layer settings”. So those uninterested in layouts won’t be irritated by another (the global) column. The one shown would obviously be the “local” column.
“View all layer settings”, of course, will display both columns - just like in layout/detail space.
So, as you say, it’s cheap and easy. The typical “low hanging fruit”, no?
One more thing: AutoCAD had two columns with regard to layer visibility:
and I never heard complaints about it. I know they do slightly different things (on/off is only for viewport, freeze/thaw also for print, or something like this), but the argument is, another column possibly wouldn’t hurt as badly as one might think…
Don’t stress yourselves too much about this…
There’s still so much waste of screen real estate in other places that a second column in the layer panel is a comapratively small problem.
“…users that never use layouts…”
True, one group os users simply don’t need them. Fair enough. As mentioned, they can use this toggle icon to hide the global bulbs (Just like it is in layout/detail space already). ‘Problem’ solved.
Another group of users does not use it because they just don’t know about it (took me a few years in the beginning to learn about it’s advantages). They might start wondering what it’s all about and check it out if they see this second column. No shame in getting people to learn about and use layout space!
The third part has tried out layouts and noticed they still sck… (to some degree).
So please continue to invest in making layout space 21st century ready!
It’s desirable (for most industries, ihmo) to have, if needed, a clean separation between 3D and 2D space. Remember this thread?
2d space should mature enough to quickly produce usable, good looking projections of objects in 3d space, and invite for graphical work.
(Just found more inconsistencies and posted them here.)
Thanks!
I agree with @Eugen.
A bulb for model space and a bulb for layout/ details.The way I see it is that if you use a layout view, the bulb should show/hide the layer for all detail views. Local overrides happen in active detail views, in which case, I think it should show that an override was made in a detail (perhaps with a right click menu to show which detail this occurred). I would argue the same should apply to lineweights and such. The model space bulb should be the master switch and can be used to toggle both layout and model space simultaneously. But it might as well not be connected.
Recap, for those still unaware of the original problem in R7: switching bulbs in model space broke all layouts and details, which is a catastrophy. Therefore, bulb switching during work in model space should be local to model space = leave the layout/detail settings. This would require a new local bulb column in model space. Since global switching can be useful nonetheless, the original global column should remain.
My phrasing was a bit vague in the last post, I see now. What I was thinking is this:
if you only touch the model space bulb, it will act as a master switch (it toggles both model & layout). As soon as you touch the layout bulb, it will be disconnected from the model space bulb.* Then, you would have the additional overrides between detail and layout views, which are displayed when you change the detail view visibility locally. Basically what happens to the single bulb in the current WIP, but then it should only ever affect the layout/ detail view bulb.
*There will be an option to explicitly link it back to the model space bulb you want to avoid accidental disconnections.
Hope that makes more sense now.
———
Then there needs to be a clear way to see overrides and where they may occur. In Revit you have these Visibility/ Graphics windows and view templates which you associate to a particular view. When you see a template name, you know which ‘layers’ are shown or hidden and what their overrides are for colour, lineweight, linetype and hatch. Without such a thing, it’ll be a lot of guessing on the applied settings per view, I am afraid.
That’s because there is no proper overview: the layers panel changes view dependently, so you can only really see local changes, whereas you need to see the default (global) setting and the local overrides.
I use Rhino for rendering since years and my clients and I like the good old simple layer system, we don’t use drawings and we don’t like to disable layers for specific views only. I think the old workflow should be possible per default. Who like can use special layer features per extra clicks, but per default a simple click on the layer bulb should disable it like before.
Or did I misunderstood the new system? Can I work like before and ignore them?
Linking to a thread discussing some difficulties this system poses with vray (and presumably other rendering software) where layers hidden in model space (grey bulb) continue to render. Setting layers to hidden everywhere (red bulb) hides them as would be expected.
Troubleshooting the issue brought me to this thread. While I love the change as way to make detail views far more useful (no need to remember which layers should be enabled to export any one view) the current system doesn’t work well. The fact that I spent several hours trying to find the problem speaks to the intuitiveness of the current system and UI. I think that default behaviour should be that grey bulb or red bulb layers should not appear in renders, but that may be an issue to sort out on the Chaos end rather than the McNeel one.
Edit: One change I would like to see is for new detail views to inherit the current model view layers. As it is I create a view, create a layout, and then waste time matching the layers from the view to the ones of the layout.
Also, I’d like to see commands “AllLayersOn”, “AllLayersOff”, “AllLayersOnInDetail”, “AllLayersOffInDetail”. I’m aware that macros or simple scripts could be used.
Because when I create a new layout plus detail, I see at first all layers in that detail. Total chaos… Better to have them all off at first (using hypothetical “AllLayersOffInDetail”), then turn on only what is needed.
Just to review, these commands are already available by right clicking on the bulb in a detail.
Visibility per view (now both model or the details) is an override to the global.
Currently, the new details is created using the the global state.
It will be more obvious when there is a global column is made available.
You should consider that the WIP is a beta build. Therefore, you shouldn’t expect Vray to be compatible with all the latest changes. It is customary in software development to only support major releases, not Beta products (if they do you are lucky). The reason being: it takes time to incorporate changes and you don’t want your plugin to rely on a system that can change in a whim (like the layer visibility improvements).
One more reason why I think my suggestion with 2 bulbs in model space is preferable:
LayerStates should be compatible across all spaces!
As of now, layout and detail LayerStates are compatible, but model space has it’'s own.
I often wished I could transfer my model space layer state across to layouts and vice versa, which is not possible yet.
If all spaces had the same layer panel ‘configuration’ (2 bulb columns), this would be a simple thing to do. At least a logical one from a user perspective.
Thanks!
There’s a reason why Revit has show/hide, view based visibility and view templates. It may sound convoluted, but more controls always prevails over having too few. In the first case, you can get your work done. In the second, you are fighting the tools and can’t get what you want.
This feature causes unexpected results when rendering with V-Ray @Micha@Nikolay . It seems that the new layer control doesn’t let V-Ray consider the layers hidden in the Model space and render them anyway for example, I set up this simple scene in Rhino 7:
When rendering in V7, the hidden layer won’t be translated as expected:
I believe the Rhino 8’s layer control is something under refactoring at this point
I have a mail from Dale, saying basically that all problems will be resolved when the refactoring is complete.
Nevertheless our support team was quick to log a ticket based on this post:
Since V-Ray’s code for V7 and V8 is the same, and it obviously works in V7, I believe this [ Rhino issue ] will shortly be resolved
Hi @mary! I am getting trouble with the new layer visibility fuction “model on” when I reshow the layer by the default layer visibility control after restoring a layer state.
Kindly see the workflow outlined below to have a check and try to repeat the scenario.
step 1:
Let’s refer to layer “A” as the selected layer on the screenshot, and it has the green color object.
step3:
now want to reshow layer “A” by clicking on the default visibility bulb, but the “model on” bulb is not in sync, and it should be “on” with the left in the meantime expected.
