Request for Cameras again

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.

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

Thanks Andrew,
I didn’t know about namedview widgets, so this is handy.
Playing around with them, I find myself wanting to select a widget in the viewport and then restore it. At the moment I have to select the widget, look at it’s name, find it in the namedview window, select it there, then click ‘restore’.
I wonder if there could be an option button on the widget itself like the gumball has for dragging options? Or perhaps double-clicking on the widget could restore it?

1 Like


Logged as

  • Andy
1 Like

… if there is a feature that many people aren’t using because the usability isn’t ideal…

That seems like a lot of assumption pulled out of the air. First, what percentage of users are not using the function? Second, is it because usability is problematic, or because it’s not required for their workflow?

Most people I know just ignore cameras…

McNeel is very good at taking customer input, but I wonder what percentage of them are made up of the people you know. I personally have no use for what you’re requesting, and it would be a feature I never use no matter how easy to use McNeel makes it. There are other features I’d like to see more development on before cameras, but I recognize my needs may not represent most users, and quite likely would result in an unused feature for some.

Andy, thanks for your thorough response. Always appreciated.

I now understand how we got cameras and named view widgets but I still don’t understand why this is where McNeel landed. It still seems most clear to just have them all be one thing.

Here lies the fundamental behavior that will keep me from using the named view widgets to their full potential and cause continued frustration. I want to set them up to have a relationship to geometry without loosing track or changing the relationship between. It makes sense to have the ability to control when they are hidden without fear of hitting ESC too many times and needing to go back to the named view panel, select the right named views, and check the “show widgets” box every single time they are hidden. The custom button will help those who read this thread and advanced users but no one else.

Perhaps we need _CameraWidgetsON / _CameraWidgetsOFF or a checkbox in Options that will force them always on (and maybe allow us to toss them on a layer to toggle on/off that way if we so choose.)

I keep thinking back to a project I worked on earlier this year that required iterating scenes where, depending on the composition, the camera needed to maintain a relationship to either the foreground, midground, or background geometry. Having the abilities discussed here integrated in the named view widgets would have streamlined that process.