OneView Label

I just found out that one can use custom named CPlanes while OneView is enabled. Nice.
… And I added my vote to snapping to named CPlanes as well.

There’s a buglet with viewport labels, though.


  • 4 viewports.

Steps taken:

  • Make a custom CPlane, making a plane that is at some angle with the World XY.
  • in the NamedCPlanes panel, activate this named CPlane in the top viewport.


  • The viewport label stays “Top”.
  • When I do the same in the perspective viewport, the label reads “User

I expect the behavior as in the perspective view.

– More observation after some more testing.

  • When I call the Plan command in the top view, the label turns “User” as expected.

This command is for setting the working CPlane - not for setting up viewports…

YouTrack filed: RH-42717

Can you tell me all the settings of your _OneView command? With the default, I don’t seem to be able to get what you state. I think I am able to reproduce once I set “ReturnCPlaneToTop=No”. Is it the same that you are seeing?


Giulio Piacentino
for Robert McNeel & Associates

No, sorry…

Enabled = Yes
Angle = 15
UpdateCPlane = Yes
ReturnCPlaneToTop = Yes
ViewLabel = Yes

Oh yes, by switching I think I can see this as well. At this point I haven’t tested anything in the debugger, but it seems that the CPlane “does not stick” once one tries to pan or rotate the view. Is that right?

You see, perspective and orthogonal views behave slightly differently, enough that probably the same code will not get to the same results. Generally, I think it’s a mistake that _OneView is applied indiscriminately to all views. It only makes sense in perspective views IMO.

@wim @theoutside @pascal what do you think?

I agree 100%.
I guess that would be the better “issue report” - rather than me complaining about the viewport title being wrong. It shouldn’t be there at all.

That would be RH-41613, wouldn’t it? Or perhaps that’s limited to snapping to custom CPlanes…

@piac, just checking…

In RH-42717 you write:

Decision is to remove label and behavior in non-perspective views as per discussion.

and the YT issue is closed. I agree with the decision but do not see this implemented in today’s daily.
bozo references branch 6.x and 7.x - does that mean that this will be in RH6.1?

Yes Release Target and Git branches indicate that the issue was fixed for Rhino 6 SR1. Sorry it was too late to update SR0, only critical stability fixes were planned to go into there. @wim

Also, sometimes these changes require changes in the Help files.

1 Like

Well, as the Help is no longer a CHM file that is an integral part of Rhino but just a series of Web pages that can be modified at any time, this doesn’t present a particular problem anymore… or what?


Well it wouldn’t be a good plan, one that bases itself on releasing a product with features that are undocumented, or wrongly documented. If it did go into a released branch, it would have required immediate attention or the cost of delaying shipping.

Yes, but previously, one couldn’t add virtually any feature during the lifetime of an entire version of Rhino for the reason that it would put the Help files out of date - at least that was the argument that was often given.

What I’m trying to say here is that should no longer be an argument, and fixing/publishing a Help page (depending on the change) may not require a whole lot of time.

And you know as well as I that there are still quite a number of “undocumented” features in Rhino… :stuck_out_tongue_winking_eye:

This is not the case. We develop new features in WIP time, and there the idea is to be more inclined to accept inconsistency with docs.

It needs to be fixed for a released product.

This simply went according to plan. Those others might each have a special reason, or be bugs.