Understanding World Front & Right

I am doing a test and reading what Mitch said here …

I am probably mixing the Cplane / World Front from the RMB click menu options for the command line Cplane / Front option. (I will try that one in a minute), but here is my question.

I create a few objects in standard new file …

If I change my Perspective to World Front from here …

I get this …

This seems wrong to me. If from my original plane start, this would be World Right.

World Front, to me should be this …

Is there something I am not understanding about World Coordinates?

I think you made a mistake there… Look at your last images, the popup menu says:

Repeat * World Right

So it looks like CPlane World Right got executed, not CPlane Front. Or is it possible that those menu items in Mac Rhino are hooked up wrong…?

In any case, it seems to be working correctly here


I think that is it. From your screencast, it works correct, from from your Windows World Front you get what I get in World Right.

I hope you can play MOV files, looking into the Jing thing.

World Right is Wrong.mov (8.8 MB)

The mystery continues…

Thanks for taking up the torch on this, Randy.

Well if “the Menu Items are hooked up wrong” then it would explain somethings.

My current belief (if it’s not evident):

The menu method appears to always show World orientation, regardless of CPlanes or UPlane enabling.

The SetView method always relates to The CPlane in that view, regardless of UPlane enabling.

Neither seems entirely beneficial. ~Dave

[edit: and this seems inconsistent at best and confusing at worst]

That is correct. Note from the menu item it is CPlane WORLD Top. World is not relative, it is always absolute. Personally I find that reassuring and not confusing.

The SetView command changes the view in a viewport. Now, what CPlane gets activated depends on what the view is named and the setting in Options/Preferences>View “Named views set CPlane”. If that is checked, yes, then setting Top view will set Top CPlane. If not, it will not reset the CPlane in the viewport when you change the view. You can prove this yourself.

  1. Start with a standard 4 viewport setup, grid showing in all viewports
  2. In the Perspective viewport, set the CPlane to World Front (see the grid change position)
  3. Make sure “Named views set CPlane” is NOT checked.
  4. From the Menu, in the Perspective viewport, select Set view > Top.
  5. Note that you don’t see the grid. Try drawing a rectangle. You won’t be able to, the CPlane is not set to Top, it is still set to Front; you’re looking at the CPlane edge-on.


Works here, cannot see the cursor with the line through circle when trying to draw the rectangle.

The Mac version looks much different. Have a look.

I was afraid of that… OK, I’ll dig out my old MBP and fire it up.


Wow, THEY ARE hooked up backwards in Mac Rhino 5.1… in the right-click viewport title menu. They work correctly from the main View menu, tool palette or from the command line.

@dan I filed this as a bug, in the meantime, I guess stick to setting those CPlanes from the main view menu, the palette buttons or typing the commands.

Nice find ! Odd that nobody has seen this before. IIRC at one point they wanted to do away with all the right click viewport menu functionality as being distinctly un-Mac-like, but there were enough protests that it stayed in. But maybe not many people use the viewport menus, perhaps an explanation as to why this hasn’t been discovered previously. Or maybe nobody ever changes CPlanes. :stuck_out_tongue_winking_eye:


Maybe it is all my early years on Windows, but I for one like the RMB options and that is all I use to change them, but like your say …

Guilty as charged!

Bonne soirée (nuit)

Glory be. I’ve not entirely lost my sanity (…yet)!

Thanks for slugging through this, all. ~Dave

Out of curiosity, I looked back at the previous topic that initially raised whether the behavior in question was a bug in MacRhino. More than 50 comments later, the conclusion is Yes.

While a good deal of information was shared about CPlanes, UPlanes, etc, given the amount of time and bandwidth involved, maybe this has also been a “learning opportunity” for us? Given the dominance of WinRhino users (knowledge, features, and experience), one humble suggestion might be for us all to be clear whether we are actually testing things in MacRhino, WinRhino, or both?

Bug diagnosis is not always easy stuff; however, that one detail might have significantly helped streamline this inquiry (and others in the future).


I am assuming that if it is posted in the Rhino For Mac category …

  • The person is working on that platform.

If it has to be compared to what is happening on Rhino for Windows, a possible bug for example, then if screenshots are included we can tell if it is from Windows or Mac. If not then hopefully the person will say in the post that this is how it works on Windows Rhino.

If someone is asking about a command or some help then that is reliant on the category they post on.

The odd categories for me would be “Scripting” and “Rhino Development” (now that plugins can be written with Rhino for Mac). It is hard to know which platform the person is on unless they say so. And we know that certain things, in python for example are implemented on Mac yet or work differently. If it is Visual basic .rvb files, we know these are Windows only questions.

Agreed. But it seems this was our first mistake! :smile:


In this post only, Mitch was comparing what I was getting on Mac to what he was getting on Windows, so in this case all is OK. The wrong hookup is with Rhino for Mac.


Note that in this particular topic, the suggestion that the Mac side might have a problem came in the second post (i.e. the first response).

In the other topic with 50 posts you mentioned, it was first about moving the cursor vertically, then about axis colors, then about the AutoCPlane plug-in all while following a general discussion about CPlanes - relative to both platforms. UPlanes first got mentioned in post #45. My opinion was, and still is, that they are unreliable on either platform with the procedures you outlined. And pretty much everything I posted in that topic does apply to both platforms.

When there is reason to test on Mac, I do. Pretty much every day, especially for scripting purposes. That’s also how I discovered the grid settings bug I posted after, in trying to create an example to test Randy’s theory that the viewport right click menus might be hooked up incorrectly. Fortunately I am a Windows user and my first reflex was to use the right-click viewport title menu and not the others…


Good for us that you are using both platforms.

Bug testing has only come by beta testing Rhino for Mac & WinRrhino 5 & 6 and contributing here for the last 7-8 years. Mostly I am here to help & learn new ways of working.

Onwards & upwards :microscope:+ :telescope:

Couldn’t agree more! ~Dave