Request for Cameras again

I’m sorry McNeel folks. Named views just aren’t cutting it.
First, it’s very foreign. Since it’s not an object, it has it’s own challenges. Like, you can’t select your “camera” and edit properties while your in the top view, for instance. Because it will show you the properties of the top view, even though you’re hoping to manipulate the camera.

And when you’re in a named view, you can move it still, and it doesn’t update the named view. So now you have a window that says the name of your view, and it’s moving your camera around, and making changes, but you Also have a saved named view that isn’t linked to that.

Rather than just having a camera object, you’re just storing definitions of where you want things. One is just for viewports, and one is memory of a viewport. Come on, there’s Got to be a fairly good reason that No one else does it like that. Lets just all admit we would be better off with actual camera objects moving forward.


What actual problem are you having? What am I trying to solve?

Geez, Andy, that’s pretty curt. Almost as if you didn’t even try to think about what he’s saying.

@kalamazandy How about another try? I haven’t used named views so I had a tough time understanding your difficulties. What are you using them for and how do they they fit in your workflow? What aspects of your view are you trying to capture and when and why would you recall a named view? What do you mean in more detail about the camera and properties selection?

I don’t know if these are the right questions for Andy, but I think the answers would help me to understand whether named views have any potential for me.

with the _Camera command you can turn on the active viewport’s camera in other viewports and edit it:

You cannot edit NamedViews directly though. You’ll have to save and overwrite it

I know it’s rather blunt. It’s currently built in a way that seems rather like an afterthought.

I was asked to do 2D drawings of several models (yes, I’m aware this is just one case, but bare with me). They then said…“Oh, and can you also render objects in there, and also give a nice shadow underneath.”
Ok, so now I have to do the Make2D so I can output illustrator lines, eliminate some of them because, well you never want All of them, and if you remove tangents then you always want a few more right? Then I need to render the Same camera so that it lines up. I will be doing that in keyshot, but could do it in blender or even Rhino, if I had the time to learn how to make Rhino renders fast enough and figure out how to get what I needed out of it (but I’m pretty sure it’s lacking things that I need). But I’ll have to get my Make2D lines, and then render out the same camera in another software. But I have multiple files. And so I need that camera Also in those other files. Oh, and then they tell me, “No, I need these 8 different views” So now I need to do this 8 times. You can only copy and paste the cameras one at a time. If I set up all the cameras at once in one file, I should be able to import the named views from that file into the others. But being, not an object, if I need to manipulate the camera numerically, I have to do that from the viewport. You can’t do that from another view. My objects are all different sizes, and I want to use the same angle, so I’ll keep the target at zero, X and Y, and only manipulate Z. But I want the same angle, so I need to just move the whole thing up.
It’s not that it doesn’t Work. It’s not impossible. But it’s Definitely Not ideal. The same sort of tasks are more difficult to accomplish with the way it is built.

Other software, like Blender and Keyshot, import the saved views from Rhino as cameras. In fact, they import ALL of the views, even Front, Right, Top, and Perspective.
In most software, a saved camera is a physical object that you can select, move, and manipulate. You can place them on layers, and even group them along with objects.

The named views just haven’t changed, in my opinion, in all too long. I asked some of the dedicated Rhino users here how often they use them. Everyone’s response was, “Nah, I don’t really use them. It’s too much of a pain.”

Named views really aren’t much different than having an actual camera. Rhino would probably want to add a few features to help people out, like giving a preview of the field of view through the viewport so the user understands what will actually render. Blender does this well. Keyshot just truncates everything outside of the field of view, which is acceptable also.

I apologize if I hurt anyone’s feelings being blunt about it. But one of the great things about Rhino is that it is used across a wide range of industries. Architecture, entertainment, jewelry, industrial design, furniture, boats, planes (yeah, I know those are ID too, but usually rather more specific).
If you can create cameras more easily in Rhino, people are more likely to create them in Rhino. It would be quite nice if say, the creator of the file set up a few ideal camera shots in their file. Then it wouldn’t matter if it were headed toward keyshot, blender, maya, etc. It’s been communicated in Rhino.

1 Like

Yes, I’m aware of the camera command. One big drawback to that is, that it lets you manipulate the viewport. It does Not let you manipulate the named view. you have to manipulate it there, THEN save over the named view again. (another reason the designers think it’s a pain in the butt).

You get to see that it’s a camera, but not treated as a selectable object. You can move the points. You can manipulate the view, but you can’t use it in another file unless you save back over the named view. One of the very confusing parts of that, other than that not being obvious when you’re working on it, is that you now have a viewport named the same as a named view, but it’s not actually the SAME as the named view, until you save it again.

(And I see now that you said that, but it was a single line paragraph below the link. Sorry)


OK- so you can edit a named view using a “Named view widget”. In the Named Views panel, select a view and check the “Show named view widget” checkbox - you will get a camera you can edit, and you will be directly editing the named view.

So in other words - we have cameras. You just have to turn them on.

There is also a way to edit a named view by looking. It looks to me like you haven’t tried any of these tools.

As I understand your request, it is essentially - I would like named views to be exported as cameras in some specific file formats. Is that correct? If so, that should be an easy thing to implement. Just tell me which file format you want us to do it for.

Hi Andy,
No problem!

At least in the new WIP the viewport title will be marked with an asterisk * if the view has been modified from the saved NamedView.

Well that’s an improvement.
But my point in this is really, if there is a feature that many people aren’t using because the usability isn’t ideal, then it should be addressed if it can be.

Most people I know just ignore cameras in Rhino completely, and set them up elsewhere. These are the only cases I’ve actually Had to use them in Rhino. I’ve used them before, but then realized, there were more steps to accomplish what is needed, so wasn’t worth the time. It IS nice that you can import a saved view from a different file without importing anything else though. If I want a certain part from one file, I have to open it and copy and paste, or open it and export just those parts. Which, for really large files, that should be avoided when possible.

Lots of people use Named views. I see models come in here all the time with a lot of named views in…

And I also get comments and requests for named views all the time…so clearly people are using them.

Which part of the usability isn’t “ideal” in your point of view? What is it about the way Named Views functions right now that makes it difficult for you to use?

Ideally your answer would not be “because it’s not like package X Y or Z”

1 Like

I would love to have the ability to see, adjust, and copy multiple cameras in a scene as an object. It would great to have this work with detail views in layouts, too. This touches on the discussion in this thread.

“See” and “Adjust” you already have. Turn on the named view widgets for the views you want to see and adjust from the Named Views panel.

Copying doesn’t work though. Although you can duplicate a named view from the panel, turn on the widget and off you go.

Even Copy and Paste works if you use the context menu in the Named View Panel.

The thing that is missing is the ability to select and modify any number of the scene cameras at a time. Managing camera objects without having to fiddle with panels containing clunky thumbnail images would be beneficial towards workflows that include documentation. I know you can set “list” view and get rid of the thumbnails but I still want to manage everything within the modeling environment. This gives you the ability to create relationships between cameras and objects that work in tandem.

Separately, for the same reasons, it would be beneficial for these cameras to link-up with Detail Views in Layouts.

The details view request makes sense to me.

Otherwise…you can turn all of the cameras on for all of the named views and modify them in the scene to your heart’s content.

What am I missing?

1 Like

If you want a quick way to turn all of the cameras on, put this on a button:

_-NamedView _WidgetVisibility _All _WidgetVisible _Yes _Enter _Enter

1 Like

@andy, Thanks for logging the detail view link request.

I genuinely did not know Camera Widgets were a thing. I usually just default to using _ShowCamera. This is cool, but I have even more questions:

  1. Why do we need cameras and widgets? Can they all just be cameras? (or all widgets and rename them cameras?)
  2. I want to select a camera as if it were a widget. You cannot modify camera values like you can a selected widget in properties unless you are in an active viewport.
  3. From my perspective as a Rhino educator, it’s confusing to call it a widget. The Gumball is a widget, too, which means in this scenario we are moving a widget with a widget.
  4. _Undo does not seem to work on widgets but does on cameras. _UndoView only works if the viewport is open and made active.
  5. Its hard to select the “viewpoint” of the widget compared to on a camera, and when dragging this point, it seems to make a different modification than with the camera.
  6. Widgets have an unnecessary “camera” shape at the viewpoint. It’s just in the way.
  7. Hitting ESC closes all camera widgets!
  8. Grouping objects with widgets does not work as expected. The group is lost after closing the widget. Additionally, using _Undo on a group that contains a widget changes the widget/object relationship.

It would defiantly enhance my workflow to have the best of both rolled into one thing (Especially if they link up to detail views. :wink:)


The reason is because the “Camera” predates the named view widgets by a long time - 4 versions of Rhino.

We actually discussed this at the time, and it was decided that calling the named view widgets “cameras” would be confusing - because we already have a term in Rhino for “saved views” - and that’s “Named Views”…and named views have been in there from the beginning. So we wanted to ensure that users understood that the “Named view widget” was just a representation of a named view, and not a new thing.

1 Like

Yes - this is a limitation of the “old school” camera, which really just gives you some grips on a view. Of course, you have all of the same properties on the viewport properties page as you do for named view widgets…so these aren’t missing.

1 Like