Is there any way to show the name of the active CPlane in each viewport, or a plugin that will do the same? I’ve just been caught out for the nth time today drawing on the wrong plane and the novelty is wearing off…
I’ve got the CPlane as one of the selected items that flicks by on the status bar, but it’s not great. Having the active CPlane showing alongside the viewport name in the top left hand corner would be ideal. Better still, make that name a drop-down list of the available CPlanes to speed up changing Planes.
Hi Matt - the NamedCplane panel will let you change cplanes quickly - double click on one.
I suppose if the active plane is a built in one, or a named one - remember it need not be either of these - then it might be possible to highlight it in this panel - I’ll ask.
Hi Pascal - Wouldn’t it be far cleaner as a user interface to have it showing at the point of access, in each Viewport? I’ve got the Named CPlanes panel permanently docked and on show, but it doesn’t tell you which CPlane is active in each viewport. I only use it to set the active Plane. It provides no feedback/status once that’s done.
Yes, in my case I’ve got a lot of custom named CPlanes (Mplanes also need to be in the mix as I use those too) but I don’t see that these need to be discriminated compared to the out-of-the-box Rhino CPlanes. They’re all there to do the same job - help the user to get lines drawn where they want them.
right, I was suggesting that it could, possibly, do that. There may also be other ways but that one seems like a good thing to try to take advantage of.
what I mean is that you can make cplanes on the fly - not named or anything - so potentially there would be nothing to show, if you see what I mean. Which is why it kind of makes sense to me to put this on the named cplanes panel’s job description.
Yes, but that’s not the issue here. If someone wants to play quick ‘n’ dirty with their CPlanes, that’s up to them. What I’m talking about is management of CPlanes (and MPlanes - they are very useful when setting up models), and being able to get back to one that was set up previously, as quickly and painlessly as possible. Named planes provides that functionality but the management of them is, well, pants.
…and then I want to be able to do the above in each Viewport independently. Then be able to tell which CPlane is active in each viewport, after the fact. For that, the current Named CPlanes panel is all but useless? Presumably you’re saying that it could dynamically update by highlighting the active CPlane as you switch from one viewport to another? How would it cope if a default Plane is the active one?
There’s potential problems there, since Windows changed the way that Rhino viewports become active. Previously, mouse-over or zoom-wheel scrolling was enough to make a viewport active, so placing line points while moving from one viewport to another without interupting the command worked. Now one has to click in the viewport to make it active (I think you made me aware of that little nuance, at the time!). If you have to click in a viewport, to make it active, to be able to see which CPlane is active in that viewport, all whilst in a command, isn’t that going to get very messy?
Hi Matt - this should be the case - Rhino viewports should light up as active on mouse-over, no click needed. If not then we may need to look at Windows settings - I found this
That Windows setting doesn’t enable what we’re after. All it does is allow one to scroll (be that zoom in Rhino, or scroll a page in e.g. Excel). It does work, to the letter of the Windows dialogue description, in that it allows the scroll wheel to work in Rhino on mouse-over. What it doesn’t do (and hasn’t for some time) is make a Viewport active, as denoted by the Viewport title going dark/bold; that got broken by Windows quite some time ago.
Yes, you’re right, it does. But I have no way of seeing what CPlane is active in each Viewport as I do that.
The set-up to do such things may need to be pre-meditated but at the moment it’s needlessly painful. If you find that you’ve got the wrong CPlane set mid-command, or even switch CPlanes in the same Viewport mid-command, it gets tricky. Can you change on the fly?
Right, I get the underlying request - just making sure Rhino is doing what it is supposed to…
@MattE - in the ‘rotating info’ status bar pane, bottom right, you can select just the active cplane entry and that will always show. If this were modified so that Front,Right, Top etc were included in addition to named planes, would that be helpful? Would it be adequate?
Here is a start - RH-67235 CPlane: Show the current
I believe that all construction planes, including default CPlanes, should have names. If Rhino users have the ability to customize the status bar, most of them will display name of active viewport CPlane in the status bar.
In my opinion, the Status bar of Rhino is under-utilized. Even at the basic and most popular 1080p screen resolution, the Status bar’s width takes almost half of the real estate of the screen. That’s a lot of space to show valuable information, but sadly, the majority of it is leaved blank.
I suggest to be able to show multiple items in the status bar simultaneously, such like used system memory, the name of the currently selected object(s) /only if they have the same name, otherwise it should mention “Multiple names”/, selected object count, selected object layer etc. Showing only one of these at a time is quite limiting since it requires waiting several seconds for the user to be able to see the necessary information.
Also, it would be far more useful to finally implement an optional permanently visible list with all the objects in the file (just like many other 3d programs), that could be also arranged by object type and filtered to be shown or hidden in the list based on their type. For example, the user should be able to choose to see only surfaces and polysurfaces in the list, while the remaining object types won’t be listed there if not needed. Note that this is not hiding the actual objects from the viewport, it’s just hiding them from the list of scene objects in this particular window. that pop-up window must be dockable, lockable, and should support opening and closing via a key or a key combination. The objects list must be able to include every object in the scene, even those that are currently hidden or locked. It must show the layer where each object is located, too. The latter will help with finding “lost” objects that were accidentally put into some hidden layer that the user can’t figure out and thinks it’s missing, while in reality it still exists somewhere.
PS: I just created a dedicated topic about the last request:
As @Bobi says, there’s a lot of wasted screen space in the status bar on larger monitors. I have Rhino spanning 2 of 3 monitors; the status bar space on the second monitor has nothing on display and there’s no way to put anything there. I can see why the ‘rotating info’ thing was implemented, but I don’t like it. I reckon I could have all of the status options permanently on show, side by side (by side) in the blank space I’ve got to spare.
All of that said, I don’t think using the status bar for showing the active CPlane is good UI. The viewport and the information are too far apart. If you’re a devotee of single viewport modelling, yes it would be fine as there is then only a single permutation. I also appreciate that you’re trying to suggest a possible fix without busting lots of other stuff. As Bobi says, a ‘half-way-house’ might be to enable multiple info boxes on the status bar, and if active CPlane is selected, allow it per viewport and show the viewport name as well as the CPlane name? Not ideal, but at least the information would then be on show.
I believe that entire status bar should be filled with data selected by the Rhino users. I disagree about the viewport and the information being too far apart.
Since the majority of Rhino users work on popular screen resolutions such like 1080p and 1440p, along with 4K and rarely sub-1080p, there is plenty of unused space in the Status bar that could show useful information next to each other. As I mentioned in my post above, at 1920x1080 screen resolution the Status bar is nearly half screen wide. On a 4K monitor it occupies 75% of the width. If programmed right, you can literally place at least 5-6 different things inside the Status bar divided into several boxes.
I suppose this would be a bit like the viewport decoration that OneView provides. That currently works with custom named CPlanes but only in perspective viewports:
Thanks @wim - I hadn’t looked at OneView before, but it does very much what I had in mind. However, I’d just like to be able to set an ortho view in one viewport and have it set its view to CPlane plan (Top? - what’s the functional difference between the two?), leaving the other viewports as they are.
That way, I can change an ortho view and know that I’m working in the correct CPlane for that view. I can use the perspective viewport to check that what I’m creating is what I’d intended. If I then run Make2D, the output is mapped to World XY plane and I can see / pick that up in the ‘Top’ Viewport.
Would it be possible to script this, so that either setting a user defined View or Cplane also sets the corresponding Cplane / View? Are either user-defined Cplanes or Views accessible via the command line or for scripting? I can see complications arising with this if it were used with an MPlane.
Which is the better way to go about this? Set the CPlane and let that drive the View, or set the View and let that drive the CPlane? Also, how can it be made to only take effect when an ortho view is set? There’s little point in setting a Top view of the CPlane in a perspective view - not that I can think of, anyway.
Most likely:) @pascal scripted the original prototypes of OneView and that can possibly be modified to do what you are after - but not by me… Several versions of that script were lost at some point but it looks like the following can still be downloaded:
