View Lock

It would be really helpful if one could lock a view, disabling pan and zoom in the view port. Sometimes a view gets set up and rendered and you find that you bumped the mouse at some point in setting up the rendering ... and then you have to do it again. It's a waste of time.

Along the same lines ... when you name a view and the name is displayed as the new title of the view port, if you adjust the view it does not make sense that the view port would maintain the same name, as that name references a different viewing position. when you break from the named view there should be a warning of some sort to let you know that you are no longer looking at the same angle as the one you setup and saved. i.e. in a perspective view if you break from your saved view it should revert back to "Perspective".

Replies to This Discussion

Hi Mark- probably the easiest for now is simply to save a named view once you have one that you like- v5 makes this a little slicker than in V4 but NamedView should help. In addition, in Layouts, it is possible to lock the detail views so that you cannot pan/zoom. One other tool which might be useful is NewFloatingViewport- if you make one of these you can keep it as the view to render, and not worry about the modeling viewports.

I get the viewport name problem.... this has been a pain for ever in Rhino, I'll see if we can do something to fix it- the problem has always been that it ends up being a deeper fix than it first seems.

I know this is kind of old, but I just happened to bump into this problem today. I'm using perspective matched views to moidel from photo reference. Just a light touch to the mouse wheel and the zoom was off. Didn't realize the change of viewport until I found some lines not lining up...

You can Lock a Detail in a Layout. For modeling viewports, you can save a named view. When you get the location you want to render save the view with a name. Then it's trivial to restore it later, even restore it to a different viewport.

As to the default viewport names (Top/Front/Right, etc.) we have talked about how to handle this for years but nothing really works. I think the closest we ever got was adding an asterisk to the name if it was no longer accurate. The truth is they never really meant anything anyway. They might as well be called Curly, Moe, and Larry...

What would you suggest? If a user rotates say the Right viewport so it is no longer a parallel projection view looking normal to the Front viewport, how should we indicate that change?

In this case Top/Front/Right, etc. are quite meaningful because they describe specific view port conditions which have exact parameters. You could call me Moe but in no circumstance would that be true, and doing so might cause confusion.

It seems at odds with the generally reliable accuracy of Rhino to allow viewports to have this laps in logic. I am sure there are a variety of ways to visually represent the view name when it becomes invalid. Making it grey or putting a red line through the label would be two possibilities. I could even live with the asterisk although it seems a bit subtle.

When working, one makes decisions based on the assumption that the appearance of a viewport matches its labeled status. The absence of reliability in this regard causes one to have to constantly keep an eye on this or, if the viewport and label become disconected, make wasteful mistakes.

The situation becomes even more dangerous in user defined perspective views because they are often set up as fixed rendering viewpoints. It is unusually easy to bump your mouse or trackpad and tweak your defined view. If you then render that view for a few hours you have made a costly mistake. And this was the impetus for the original post requesting a view lock to make sure this kind of mistake will not occur.

In InDesign there is a similar problem with image frames that are prone to slight movement over time. There is a facility for locking and unlocking frames which is critical. Not exactly the same issue but closely related.

I do, as you suggest try to remember to re-click the custom view name before each rendering. But I still occasionally forget and end up wasting the odd rendering which I think is unnecessary.

It seems at odds with the generally reliable accuracy of Rhino to allow viewports to have this laps in logic. I am sure there are a variety of ways to visually represent the view name when it becomes invalid. Making it grey or putting a red line through the label would be two possibilities. I could even live with the asterisk although it seems a bit subtle.

Well said. More generally, software is easier to use when it reduces the number of things you must remember to do to derive valid output. If software makes odd conditions obvious, it reminds the user of them, letting her make the appropriate corrections. Even better, it can permit her to elect to completely avoid certain odd conditions.