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.

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

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?
Cheers,
Steven

1 Like

Steven

Logged as https://mcneel.myjetbrains.com/youtrack/issue/RH-60554

  • 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.

I just tried it out and even though I have used named views a lot, I have never noticed the “Create using widget” part. The naming and/or icon is far from ideal. Why not just say “Create Camera” or “Create Named View”.

Also editing the camera is a bit strange: You get just one gumball in the middle of the camera, whereas usually you would have one gumball for the camera (which is aligned to the camera and not world) and then you have one gumball for the target, which IS aligned to the world. Strangely if you click on properties for a camera, you see the location for the camera and target.

Lastly, I agree that things like this should be “selectable”. And once again all of this would be so much easier if we just had an object selector and not just a layer list. I still don’t understand why everything has to be so omminously separated, when you could just have an outliner with layers and the objects in them (yes, including cameras/named views).

Sorry to say this @andy, but there is a reason that literally all other 3D programs have it and therefore also warrants the comparison to them, just like many other things that are sort of standards in the 3D world. If Rhino is the odd one out, then there must be a very good reason for not having it. Ideally your answer would not be “because that’s just how it is/always was”.

1 Like

Also I just noticed that whenever I interact with named views I get:

Everything seems to work okay, but the errors are clearly a bug.

(Rhino 6.34, Windows 10, Nvidia GTX1080ti with latest studio drivers)

Just saw your reply. I actually need something similar and have been playing with V-Ray for Grasshopper nodes, as well as the nodes in Heteroptera, which include a node to control the camera/view in Rhino.

I think it makes sense to just rebuild “cameras” in Grasshopper and use that, since you then can choose target objects and the like. I’m sure it will be better than the named views we have in Rhino currently, for this usecase.

I will investigate and report back…