Request for Cameras again

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.

https://mcneel.myjetbrains.com/youtrack/issue/RH-60514

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:)

2 Likes

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

OK - but that’s why they both are…a manipulator for some underlying object. And sure - you can use the Gumball to manipulate another manipulator…I don’t see that as being particularly odd.

Incidentally, there are two other widgets in Rhino: The mapping widget and the decal widget, both of which act in a very similar way to the named view widget.

1 Like

This is a bug, which I will now log.

https://mcneel.myjetbrains.com/youtrack/issue/RH-60523

1 Like

This is because it’s possible to pick and move the whole named view widget, but that’s not possible with the camera icon…so a choice has to be made.

I don’t see that the modification is different.

1 Like

This is there to make them distinct from the camera icon.

1 Like

This is the case for all widgets in Rhino.

1 Like

Yes - this is an unfortunate consequence of the widget behaviour - it’s really just a manipulator, not an object…so you can’t put them in groups.

1 Like