Modeling Views should be more like Detail Views

Why is there a division between Detail Views and modeling Viewports at all, with consequences such as duplicated color, layer visibility and object display? Wouldn’t it be simpler if Viewport could be assigned to a given set of display settings settings (hereinafter I call it Visual Set)? Why not allow full-fledged work in viewports with custom visibility?

One of the main things that can’t be done right now and that I miss, is working with Viewports that have different visibility properties of layers or objects. Working in Revit, for example, it’s perfectly normal to have multiple views of the same elements, but each view is used to focus on a different aspect. For example, we can work on a building, but one viewport will be used to work on the interior arrangement, and another for the arrangement of installation openings in walls and ceilings. When working on openings, we don’t want to have a view cluttered with furniture or dimensions, we want to be able to focus on the selected problem to be solved. Limiting visibility, or highlighting one aspect with color really, really facilitates the work and help focus on work instead of fiddling with Rhino settings.

Viewports should correspond to how we perceive objects, whether objects are visible and what visual features they have. Meanwhile, in Rhino, it’s the other way around - visibility properties are assigned to objects instead of viewports.

Some of these settings are available in Viewports placed on Layouts, but you can’t work with them to do modelling due to how camera works. If it would be possible, I would really like to sink in one of those Layout Viewports, and escape from it when I want to enter different viewport.

Using Rhino can be tricky because visibility changes that we expect in one viewport and (perhaps only for a moment) create global changes for the whole model. A lot of time is wasted trying to keep visibility in order, making global display changes and backing out of those changes. Layer States are not the answer to the problem because they adapt poorly to project development and quickly become obsolete, incomplete settings as there are new layers and objects.

One of the most important things I want to convey is that you should be able to customize the display of one view without worrying about messing up another. This would allow us to create a “quick-dirty” view where we can doodle something, check some idea, and not mess up other views.

Wouldn’t it be better to have something like mentioned Visual Sets?

Visual Set could be applied to any Viewport. Multiple Viewports could be assigned to the same Visual Set, there could be overrides etc.

For example, in the Rhino window at the same time we could have 4 Viewports with two different Visual Sets.

In this photo montage, I have one viewport for detail modeling of the red and blue objects, but I want to see its surroundings at the same time and they are displayed in other viewports.

Here I want one view to focus on selected aspects. One Viewport displays distances between elements and another showed them in 3D without dimensions (and with one element displayed in a special way). Other viewports show the full scene. Mentioned dimensions could be on a layer displayed only in Visibility Set 2 or are hidden as objects in all other View Sets

I have the impression that currently in Rhino there are a lot of options to set the display for Detail Views on Layouts but because separating Viewports for Modeling and Viewports for Layouts, there is unnecessary complexity, duplication of settings and it limits the ability to work on the model with given settings.



Makes sense and I totally agree. You got the words out of my mind haha.

Any ideas to implement this in V8 or in the future @dale @stevebaer ?


I more and more like that idea! Rhino’s approach to what is shown in a viewport and how is indeed unnecessary complex, and not particularly logical. Grown instead of conceived.

An existing feature that comes close to this “visual set” idea are Snapshots - they hold the complete set of parameters influencing a viewport. A feature that might be a bit underrated. Does anyone use actually use them? We could contemplate on how to put them to better use.

  • Agree with Jakub: all model space viewports should be completely decoupled, meaning object/layer visibility should be per-viewport, not per modelspace. After all, Detail viewports work in this manner already.
  • A viewport should remember which snapshot is assigned to it, with an option to auto-sync each part of the snapshot. Auto-sync means, when the snapshot changes, the viewport follows automatically. That would make it possible to even then keep multiple viewports in sync visually, because all of them use the same snapshot (=visual set), should this be preferred.

The tricky part will be not to bring even more complexity to the party.

One for the heap, since it suits the topic:
Display modes should be part of the document, not just a Rhino setting!
If you send a Rhino file to someone else, you need to separately export all your used display modes and pass them on as well, if you want the scene/viewports on the other installation to look exactly as on yours.
That’s an unnecessary nasty little tripwire!

1 Like

Going back at it a year later, not in the WIP but having Rhino 8.8.

Is there a chance that something will be done to the Model Views in the Rhino 9?

With the current system it’s very inconvenient to work on some design options/variants.

Let’s take a simple apartment design as an example. You have 3 versions of room layouts and 2 versions of the kitchen - 6 permutations.

While it’s doable to create 6 sets of Layouts with different Detail Views, it isn’t easy to work synchronously on different options because there is only one Model View setting.
You need to “destroy” your current Model View to enter a different one where you might need to spend just 10 seconds and then if you need to go back you need to modify the Layer/Object visibility once again.

Unfortunately, you can’t really work in the Detail Views, they are not suited for that.

It might not seem like a problem in a very tidy, small, and organized file, but Rhino isn’t very strict about categorizing your objects for you automatically like i.e. Revit (which BTW doesn’t have this problem because each “model view” has separate visibility settings.), so while you work it can get messy. Toggling between mess no. 1, 2, 3… is like complicating it to the 2nd power. There is a significant overhead while working in Rhino to keep things organized. Also, I’m not talking about setting Snapshots, or Layer States - that’s maybe possible when the Job is finished but while working and constantly adding and deleting Layers or Objects forget about reliable Layer States…

In short - My wish still stands: forget about this complicated Model View / Detail View separation, or keep it if you really need to, but let me work in the Model Views that can have independent visibility settings.


Fully in support of viewport-based visibility settings similar to revit. Being able to see an outline of the work (in your example, like seeing the 6 permutations, something which you can do with Revit) before you start to do the work is beneficial. It’s easier to bring others in to help on the work, or simply to spend time wisely on each option.

I have a couple strategies for managing design options in a quasi-revit manner: using blocks and a “HIDE” view setting.

Blocks have been useful to hold design options, especially if you use the same origin point. If the design options share the same features (eg, all options have windows, walls, roofs, solar panels etc.) then I create a parent layer with a set of sublayers of the shared features that all the block options reference (eg, all the walls in all options are on the walls sublayer). The block object is on its own layer to toggle visibility while the shared feature layer always remains on. It’s worked out pretty well so far managing 9 options in a masterplanning project.

The strategy kinda breaks down in detail views – you still need to toggle visibility of each block before exporting an option – and you can’t see the full set of design options in the modeling environment like you can in revit. It’s only after you export all the options, compile them in acrobat/bluebeam that you see all the options.

Another strategy is to have a view setting which doesn’t show anything–no shadows, edges, mesh wires, anything geometry at all and name it “HIDE” or something similar. You can select this view setting with “SetObjectDisplayMode” to hide geometry in a view while it remains visible in another view. It’s not perfect because of the differences in view types in Rhino, but it helps if you need to quickly hide things in a view without committing those things to hideswap or creating a layer to temporarily hide stuff. This strategy works best with view modes like Arctic or Shaded while it struggles with Pen or Technical view settings.

I also found this system with the distinction between Detail Views and Model Views something unnecessarily complicated and I wonder what kind of mistake of the past it is. It’s especially frustrating that some things are possible in the Detail Views and other in Model Views. Often I realize that my seemingly smart workaround will not do it. Designing and creating documentation in Rhino is a game in itself that distracts from thinking about the clue of the work - good design.