We are not talking about a complete overhaul here - actually just one thing: decouple the Detail layer visibility from the model space layer visibility:
This wish alone would help tremendously!
Of course it’s a good thing to debate the whole layout topic in-depth - which was done here already, to great length:
+1 for me agree with Guido
Would it be possible to have Rhino display a separate Layer properties panel for each Layout, that was shown in place of the ‘normal’ Layer properties when a Layout viewport is active? That would allow complete (and separate) control of layer visibility for each Layout. Layer State per Layout, as it were, without the need to resort to visibility in detail (which always feels clunky).
Changing layer visibility state in the model space would not affect the Layout(s).
All layers created in the model space would automatically be listed in all Layouts. However, layers added to a Layout would only appear in that Layout (perhaps listed in bold type or similar so that it is clear that they are specific to that Layout?). That could be used to add specific annotation/dimensions/geometry to each Layout without cluttering the main model space. It could also be used to import data from outside files for the purposes of providing installation details (i.e. how to fit something to something else) without the need to clutter the main model space.
Changing linetype, print width, colour etc of a layer in the model space Layers properties would also set those (initially) in the Layouts. However that could be individually over-ridden within each Layout. Very similar to the way Rhino handles object properties per layer and per object. Allow copy/paste of layers between Layouts, so that layers with specific attributes could be quickly propagated? Currently, that’s done simply enough by copying a piece of geometry from a new layer between models, so perhaps that’s the easy way to acheive same in Layouts.
There is precedent for the display of other properties panels to change dynamically dependent upon the selected viewport, so the above would’t be a new ‘behaviour’ within Rhino.
It also would be desirable to ‘link’ a Detail to a LayerState (don’t know if this idea was brought up already).
There could be a popup-list in the Detail’s parameters with all the LayerStates, plus one entry ‘local’.
If a Detail is linked to a LayerState, it would automatically overwrite this LayerState when any layer changes are done in the Detail, and vice versa, a Detail would update automatically if the LayerState was changed somewhere else.
If it’s set to ‘local’, changes to the Detail’s layers won’t affect any LayerState.
(Just had the case where I need to apply one and the same LayerState to 12 Details. If I need to change the LS, I have to click away again.)
Yes, that’s derailing the thread a bit, but it is related.
Confusingly, as it is, there are 3 different kinds of LayerStates - one for Model Space, one for Layout, one for Detail spaces, wich are not ‘compatible’. A model space Layer State cannot be applied to a Detail or Layout etc…
Suggestion: as mentioned, there could be just one set of Layer visibilty toggles in Model space, Layout space, Detail space, and the LayerStates can be ‘exchanged’. Simple as that.
Hmm. Sounds a bit confusing. You might need to go for a layer hunt if you forgot where you put something.
On second thought, this might be a good idea! ‘Local’ layers, so to say. So, +1!
Because at the moment, I ‘simulate’ layers specific to a Layout by putting them on thoroughly named sublayers of some ‘master’ layer named ‘Layouts’, and turning these off in the Layouts where they aren’t used. Works, but hey…
Dear McNeel wizards, what’s your approach now to the topic after 8 years of collating thoughts regarding this?
Thanks!
Exactly. That was the starting point that gave rise to my train of thought. Most people in these threads are saying that there’s stuff they want shown in Layouts that they really don’t want to see in model space.
For those that are using Make2D, it might also help to have an option in the Make2D dialogue to “send output to Layout XX”, where XX is chosen from a drop-down list of the Layouts in the file, or even to another Rhino file, for very similar reasons.
This is one solution to a broader problem, which I believe is this:
I want to be able to set up a layout with details with specific objects and layers visible, and I want that setup to be maintained as I work on the model in model space. This makes it possible to print the detail without having to carefully consider the layer states that have changed as I modeled.
Is this correct?
That’s correct.
And I think this applies strictly to visibility.
Other properties like material color etc should follow model updates by default (although maybe a way to override could be very useful in specific cases)
Frankly I avoid layer states and advise my team not to use them. Too often a team member accidentally restored through layer states, obsolete layer properties and saved the file. I would much prefer it if a layer state only stored selected properties so to avoid accidental overwrites …but this may be a new topic.
Yes, absolutely.
Speaking for the architectural side, this is what you can expect in programs like Revit. You create a view with it’s style and 2d objects (annotations etc), and can be sure it remains that way (except of course you delete 3d objects). Whether you change the visibility of a 3d object in a view has no effect on other views.
The Rhino way is to add Details in Layouts, then tune style and visibility in the Detail’s layer settings. I can live well with that because I consider layers as a blessing (some people don’t).
What makes no sense though is this thread’s topic - why must changes in model space layer visibility carry over to all Details?
I tried to convey a few debatable solutions, but was unsuccessful in starting a debate about them:
Agree.
A simpler tale for .1 &.3 would be the possibility to alt-click lightbulbs creating a special “locked lightbulb” with its unique icon (could be a red border or gray background) to indicate an override. That would make extra columns & checkboxes unnecessary.
Thought about that. These graphics show the layer toggle logic:
Status quo:
Your proposal, with an override in Detail/Layout space:
My proposal no. 1, where in Model space you would only toggle the local lightbulbs, and leave the global column in peace, except you absolutely need to turn off this layer everywhere:
Might be a matter of taste which way to go.
Btw., in contradiction of what I said before, of course it makes sense to also use the Layout space local toggles, since it’s possible and useful to draw directly in Layout space.
Hi all,
It is strange that the solution is already here and is being ignored.
Have you tested Safelayout suggested by @lahos above?
I was experiencing exactly the same frustration of @guido until I installed it.
Using since months now on quite crowded layer combination on many layouts and never had one issue.
Please give it a try, I think is the right behaviour to be implemented in Rhino.
No idea about how you can make some serious drafting without it!
As we are speaking about this please have a look at this old post about Rhino 8 Development where many points are related to layout and drafting
Testing it now.
I have been concentrating on the default Rhino mechanism here because this should work well out if the box. No plugin should be needed. Once everbody gets used to it, it’s easy to forget that this long standing issue needs a fix.
Btw. Another example for this phenomenon is the BlockTools plugin (SelSameBlock, MakeUnique, ResetBlockScale). These commands are so essential, they should definitely be included in Rhino.
Sure, I do agree about this,
but while we wait for Mcneelians to implement this we can do our job!
I didn’t know about BlockTools plugin and not happy about how they are managed in Rhino. Will test it then!
Can’t find it on Food4Rhino. @Eugen could you please share a link? thanks!
Allright, SafeLayout does exactly what we need, and I’m gonna use it! Nice!
HOWEVER: we should not need it! I looked into the python code, it’s an elegant hack, so to speak.
And it will be necessary to install it on every Rhino machine. Might or might not be an effort.
Here’s the link:
You will be forwarded to:
where you can dowload the 41kb package. It will be blocked, so in windows you will need to go into the properties of SafeLayout.rhp, and set the appropriate flag. You will find it.
What SafeLayout basically does: every time the user switches to Layout space, the model space layer toggles are stored automatically in a LayerState named “SafeLayout:ModelSpace”, then all ‘global’ layers are turned ON so that all Details look ok, and when Model space is activated again, the LayerState is restored.
There’s one weakness of the SafeLayout plugin: it always turns on ALL model space layers when entering Layout space. This can be undesirable, since I might want to keep some layers definitely off everywhere - one good example are attached worksessions.
Because worksessions cannot be toggled locally in a Detail, which is an additional problem:
EDIT: boy, this is confusing… I just tested if the layer settings of attached worksessions are saved in an .rws file. They are not. That means, if one is using worksessions in layouts, the layer settings have to be adjusted every time the file is opened.
Besides, there seems to be a bug: how can this
become turned off when it’s not possible to toggle it? It just happened, I don’t know why.
My preferred solution would be my proposal no 1.: model space gets local toggles (second column).
Hey Everyone,
We appreciate your input on this. This feature request is on the list and being look into.
https://mcneel.myjetbrains.com/youtrack/issue/RH-19685
Thanks,
– Dale
Hello!
The ‘SafeLayout’ plugin proves itself very useful. However, there are some shortcomings to be aware of:
What if a LayerState was automatically created as part of the New Layout command and was given the same name as the Layout, and remains linked to the Layout as long as the two have the same name? When making a new Layout, have an option to match the layer states from another (existing) LayerState to save time with setting things up, either permanently or just initially.
If the Layers panel is docked, it would automatically change to the linked layer state when each Layout is made active. That would make it much harder to mess things up between model and Layouts.
I appreciate your trying to find solutions but I have a few problems with your proposition.
My main issue with layer states is that it stores unnecessary information that if accidentally restored, will overwrite the file progress.
I believe that good tools protect you from human error, and everyone has bad days.
I see how storing material is kind of neat , and one could use it for design options as it allows to cycle through materials quickly. But its not very useful in architecture unless it records the mapping too. I would much prefer this to be dealt with separately (material states?). Same with layer colour and print settings. Never had a need to restore those. Additionally layer states doesn’t seem to get along with worksessions. And if you work in a team, on a large project, worksessions are fundamental.
I like where you are going with the matching thing,
but visibility should be matched by detail, not by layout. You are likely to have a layout with different details each with its own visibility settings.
I think that a Revit view-templates like approach would be the way to go.
I think that Rhino is formidable for certain industries. I also think that it would be dreadful if it ended up like Revit, so complex, clunky and unintuitive. I like Rhino “lean and mean”, pity that it’s just a couple of features away from being decent for documentation.
Please McNeel, allow for indipendent visibility between detail and model space. 