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.
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.
Start with a standard 4 viewport setup, grid showing in all viewports
In the Perspective viewport, set the CPlane to World Front (see the grid change position)
Make sure “Named views set CPlane” is NOT checked.
From the Menu, in the Perspective viewport, select Set view > Top.
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.
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.
@danI 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.
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.
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…
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.
+ 