Named views lie. and named view lock doesn't lock. and nameview update updates, sometimes

Rhino PaperCuts
1

In the 18+ years that I have been using Rhino I have lost 187.5 hours of productivity, or the equivalent of 4.68 work weeks, working 40/h week, by one tool an done tool alone: named views.

Why? because you let me save and name a view. so when I do any screenshots or rendering where views have to exactly match, if for some human reason I moved my camera I never know and I spend lots of times creating views that are not actually the name view that I named and saved. and even locked!

I just made a video with a current working file (added a bounding box for confidentiality reasons).

Take a lock a this bizarre movie, where I show a long comedy of errors:

  1. I change the view by rotating my camera, but the name view will stay put, like if was still correctly named/saved view.
  2. My thumbnails do not update, even after I check the update icons.
  3. They only update after I check the ‘lock view checkbox’ (not the update icons)
  4. The lock view checkbox besides wrongly updating thumbnails doesn’t seem to do anything. My view is still unlocked.

This is a terrible workflow. It’s been going on for waaaaaay too long and it needs to be fixed. It’s time.

Thanks for listening to this same complain I’ve been having for now 15 years or so. It’s time we can put some of the old complains behind so we can focus on the new ones. And don’t expect that my memory will fail, even if/when it does, I maintain a really good Serengueti folder with all my old, new, and yet-unshared Rhino UX horrors.

Who’s bugging this? who’s fixing this?

G

2

Yeah, McNeel seems to have a proclivity for dreaming up a swell-sounding name for a new feature that seems to imply wonderful new capabilities and then half-ass implementing it perhaps on a Friday night by a programmer or two with places to go and people to see.

We all like to think they’re far better than the other software companies, but it seems they are really all the same. Not much pride of workmanship to begin with, and when users complain they’re all on to the next great thing and can’t find the time to own up to their sloppy work and fix it. Resources, ya know.

Named Views isn’t the only one.

4

Being successful, having a growing business and having a really time to find enough good developers to do their work? Yeah the same as the other software, and non software companies.

Caring about our needs but having to really prioritize based on what’s most important, for most people? Not they same. I think McNeel is way more dedicated than any other software (and non-software) company I’ve dealt with. Ever tried to deal write a support problem with Autodesk, Adobe, PTC, Dassault? They are a complete embarrassment.

The reason I had to make a big deal of how long this has been hanging is because it’s like a small thing, but that overtime, if you use Rhino (with plugins of course) for visualization work, these little things can really screw up an entire project deliverable.

5

hi Gustavo,

I understand the frustration and happened a few times here and there to me as well, maybe not to that level of frustration. There definitely is some room for confusion in regards to how NamedViews work in Rhino, if you compare it to other software packages, that are Camera-based. I don’t have to explain to you how Rhino works :slight_smile: But I would say in some of the items you bring up, be careful what you wish for…

IMHO it would be terrible if changing the viewport titled as the NamedView would also automatically change the NamedView. I would find it very confusing and counterproductive. Hope that is not what you are proposing as a solution.
There is currently an option to Edit View By Looking (the “eye” icon), never find it useful but it actually changes the NamedView “on the go”.

It has been discussed before that many times the confusing part is that the view title still corresponds with NamedView name, even if the camera moved.

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

A potential proposed solutions discussed before:

  • as soon as the viewport camera doesn’t match the NamedView with the same name, the Vport title should either have [changed] suffix added, or some color indication in vport title (red frame, red square… etc.) so it is clearly visible the view is different than saved namedview

  • it would be great to have an ability to lock the viewport, not named view, so the camera can’t be changed. Current “lock” option in NamedViews doesn’t seem to be that helpful or prevent the issues you are having. If we could lock the viewport on/off, it could really stop users from accidental camera changes when needed.

  • there should be a command RestoreTitleView, that instantly restores NamedView that corresponds with current vport title. I have it scripted and use it all the time with quick key shortcut (can share if you are interested), but IMHO it should be a vanilla Rhino command.

Can’t comment on thumbnails behavior as I never use them - too slow to update on the scenes we are working with, and most of the times also have a lot of named views, so in general the thumbnails UI is unusable for us.

–jarek

6

I absolutely agree. That would be terrible and not what I propose as a solution.

These are great solutions.

RMA Team, look, Jared figures out what to do. Please just time this in the Rhino7.rhino file and save the changes. And we are done!

G

7

Gostavo - as for #3, you can get it here:

I have a key shortcut assigned to it and use it non-stop.

Windows only, If needed for Mac, maybe someone could translate to Python…

–jarek

8

image

9

Gustavo et Al

I’m the developer that works on this stuff. I’m currently out of the office and will be until Tuesday. At that point I will examine every comment in this thread, and if there is action to be taken, I will ensure that it is done. In 6.15 or WIP.

I agree that named views can be confusing and I’ll designed. I will try to use this opportunity to get them closer to what you need.

Andy

10

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

11

Two more wishes for NamedViews improvements:

  1. Allow folders/nesting
  2. allow undo of changes somehow within NamedViews dialog: countless times NamedView got accidentally deleted with no way to go back.

–jarek

12

yes please!

13

Frustrating Named Views and always underdeveloped V-Ray for Rhino were two reasons why I gave up on renderings inside Rhino. I really wish it will be made better someday.

14

Gustavo

The video has become unavailable - I assume this is a problem with discourse. Any chance you could re-post it.

  • Andy
15

here you go Andy: https://global.discourse-cdn.com/mcneel/original/3X/e/c/ecc99f1cf7c635de63d83338909294e9522ee672.mp4

also as a Dropbox link just in case:

Gustavo

PS: I really hope Discourse has not lost all the video content in this site, so much great info that it would suck if it’s gone.

16

Gustavo

Firstly, it’s absolutely clear #2 and #3 (views not updating, only updating after checking lock) are a error that is happening on your machine. I don’t see that here. You should never see black named views, and the fact that you are suggests that something a little odd happened when you opened the file.

The named view thumbnails are drawn using exactly the same code that draws the views themselves, and also the quick (non-progressive, non rendered) Material thumbnails.

That aside - I think that all of the rest of the issues described in this thread are a result of the mental model of the developer being different from that of the user - and possibly some confusion caused by some of the behavior.

At this point, I should say that I was not the original developer of Named Views. I simply wrote the UI code that puts them in a panel - first in Rhino 5. Before that, they looked this this:

image

NamedViews were designed for Rhino 1.0, and the basic design has remained unchanged since then. The basic model is that they are a list of canned views. That’s it - nothing more.

They do not interact with the viewports in any way, other than that you can set the camera position of the active viewport by restoring a named view. The confusing part here is that the name of the viewport also updates - which makes it look as though you are not “in” the named viewport.

You’re not though - the viewport title updates because generally users are going to call their named views by something meaningful - like “Living Room”, “Kitchen”, “Three quarters view”. And if the viewport title didn’t change, that information would be lost in the live view.

I find this confusing myself. But I understand why the original designer thought it was important.

What I don’t understand is why you would expect the Named Views to update when navigate in the viewport. Surely that would make Named Views pointless? If you could break them so easily? Maybe it’s because of the “Automatically update view” label - you expect it to work on the camera. That is really talking about the contents of the viewport - ie, the objects. So that what is shown in the named view preview continues to look similar to the model.

Maybe we should remove that? Or rename it?

You can, though, edit a named view by navigating a viewport. There is a specific tool for that. Right click on a named view and choose “Edit Named View by Looking…” - you get a floating viewport which is basically a named view in Edit mode.

Finally, there are the named view widgets - AKA Cameras - by which you can see the named views in the model, and edit them using the control points of the camera. This edits the named views in real time.

Most of the suggestions in this thread,I think, are rendered invalid once you grasp the correct mental model. Clearly we are not doing enough to make sure that users understand this intuitively.

  • Andy
17

I agree with Undo - unfortunately, NamedViews is one area of Rhino where the person who wrote it just didn’t bother to add this. It’s already logged as a bug.

And folders? I find that users generally don’t understand folders and nesting very well. How about tags and search?

  • Andy
18

I’m really surprised at this, since the folder concept is universally used in all OS’s for directory/file organization. Or did I misunderstand what you are trying to say?

19

hi @andy, I would let @gustojunk respond for the specifics in his original post, but have to make a few comments here to your response.

Leaving alone thumbnail updates as an obvious bug, I think that simply dismissing the feedback on NamedViews as a disconnect between developer and user’s “mental model” is too easy. This feedback comes from at least two Rhino users with 15+ years of using the software daily, and I am sure we are quite familiar with how NamedViews work and what the concept was. The suggestions for small improvements come exactly from grasping that concept and its pros and cons. The concept itself is not being questioned, nobody suggests views changing ‘on the go’ as we change the views (please see my clarification with Gustavo earlier in the conversation). But the area of confusion that he describes, and also what is seen in many other posts on this forum, is the easy disconnect between ViewTitle and NamedViews.
So - really, the lightweight NamedViews concept is great and should stay as-is, with potentially small improvements to how Rhino communicates with the user, when the viewport<>namedviews are no longer matching, or the ability to ‘lock’ the viewport so the accidental change is not possible.
So I still stand by the list of improvements suggested. Not asking for a revolutionary changes, but to recognize shortcomings and provide small tweaks to make each part of Rhino even better; something you guys at Rhino have been always really good at. From the user standpoint I appreciate these small tweaks more than big radical new features.

thanks!

I thought folders are quite intuitive… The main problem is sometimes lists of named views get very long; tag and search could help but its really about the visual clutter and ability to organize the files neatly as a critical way to deal with complex models. Maybe a Filter mode, similar to Dale’s in Layers panel instead? This is not critical wish and I can see how it would create issues with scripts / plugins that would need to be rewritten to deal with the folder structure of NamedViews properly.

thanks,

–jarek

20

Jarek (autocorrect really didn’t like your name)

Yes, please don’t take my comments as “I don’t intend to do anything to make this better”. I’m just trying to start by getting us all on the same page.

Andy

21

Were you tempted to let it be as autocorrect suggests though? Hope not, all the typing I do on this forum is to help devs like you with getting a bit out of their “mental model” of things and recognize the users “mental model”. Seems like quite often you and I differ in opinions, but I try to not give up. I believe there should be a good symbiosis between the two, as you guys don’t have days/years to actually do professional production work using Rhino and its only there where certain shortcomings or potential improvements are exposed; at the same time we, users, are not familiar with the inner workings or even what is possible in Rhino code, or your general product development strategy, other than, hopefully, to always try to make Rhino better.

Feel free to use my full first name ( Jaroslaw ) so the autocorrect is not biased :wink:

–jarek