I’ve tried various key combos that recall from a tutorial online but maybe that only applies to the windows version? I know this is fundamental, but I’d be grateful for an answer.
I guess you’re referring to Elevator Mode, which requires a command-click to move objects vertically. (it’s in the online MacRhino online help under Transforms). Other ways I find easier to grasp are simply the Gumball, the Move command with the vertical option, or just moving/dragging vertically in an orthographic viewport like Front.
–Mitch
I’m wanting to define a second point on an axis to revolve or array with for instance when in perspective I’d like to be able to move perpendicular to the plane from zero. Also, regarding revolve, I’ve attached a file and some shots. What I want to do is use an extracted edge from the object and revolve it around the other side. I use the snap to select the top corner of the eject and then revolve until I’m snapped to the other side’s corresponding point. However, there’s a gap on each as if the revolved object had revolved a bit itself.
CCPony.3dm.zip (259.0 KB)
Are you revolving a new surface because the cut out surface is not lined up cleanly to the trims in the existing bottle surface? I’d rotate the bottle or the cutout to line them up… but maybe that is not the problem…What are you trying to do here?
-Pascal
Yes I’m revolving a new surface from the extracted edge of the complex surface object. I’m expecting the new revolved surface to begin at the edge where the extracted curve is and meet up cleanly with the opposite edge
Here, there is a small ‘start angle’ already set in Revolve - not sure why - make that zero and it should work.
Just as an aside - your bottle shape already has far too many control points to keep the surface fair and clean, (CurvatureGraph getting a little jumpy). I’d say you could define the shape with maybe 8 points.
-Pascal
Well, an easy way is to click the start of the axis and then with ortho in something like the Front viewport, just pull a line up and click somewhere. Or, click the first point and type r0,0,1, which will give you a vertical axis from the start point. Lastly, Revolve at least lets you set the first point and then just hit Enter to create an axis that goes through the first point and is perpendicular to the active CPlane.
–Mitch
I chuckled a little when I saw this, Mitch, thinking of our recent exchange on Ortho.
As for Ortho, you’ll find it useful to know that any snap overrides Ortho behavior, regardless of location in 3D space… (Why this is supposedly useful, I have no idea and consider this to be a dangerous flaw). The trick to making Ortho work is to start a line and before it shows any snaps hit Tab. This locks the vector and snaps will only show up if truly orthogonal. ~Dave
Well, yes. However, to give a vertical vector, it doesn’t really matter where you snap the first point or if you snap at all, just don’t snap the second point to anything (Front viewport for example). That will ALWAYS give you a vertical direction when needed. And it’s pretty easy NOT to snap to something - as Rhino tells you on-screen when it is snapping to something. If you really need to be absolutely, really, 100% without a a doubt sure about not snapping, hit the Alt key when clicking. It’s not rocket science.
–Mitch
1 Like
I have to respectfully disagree here, Mitch. Sorry…
Experienced Rhino users (myself included) frequently overlook the fact that a few of the working methods in Rhino require intimate knowledge of “how things in Rhino work”. Forgetting that many of these methods rely on insights that are non-intuitive and/or hard won, gained over hours and hours of use, RTFM, and user-forum interaction. What is often overlooked is that in some cases, these methods are less than optimal workarounds for clumsy (or even problematic) behaviors.
I firmly believe that both Snaps and Ortho behavior falls into this category and both could (and in Ortho’s case, without doubt should) be improved—especially if (new) user happiness is of interest. (I realize “happiness” is not always the singular and primary motivator for McNeel & Assocs, since complex problems are sometimes more interesting or fun to solve).
The reality is that we are seeing lots of questions about fairly simple things like Snaps, Ortho, and Relative Moves as new users give MacRhino a whirl. This alone should be a clue that there is an opportunity to improve something, and a big reason why new users are so valuable—they are not yet (ab)used to the way things are currently done. They just want things to work in a somewhat intuitive fashion (and they’ve often become used to better behavior in other programs). It’s worth noting that the vast majority posting questions on these topics are bright, articulate, and often very experienced with other software. However many are confused, frustrated, and/or stumped about a few simple topics—and, honestly, it’s not usually their fault!
Enclosed is an image and a Rhino file illustrating why I continue to feel that a few very simple acts of drawing are currently overly cumbersome at best, and/or extremely confusing at worst. Go ahead and give it a shot yourself.
Start the line in Perspective where indicated and end it in the Front view. Imagine that you’re a new user (possibly with even decades of experience in another program), but you have no idea about the use of Alt or Tab while drawing (and I’ve met a surprising number of experienced users who are unaware of either!). You’re just trying to draw simple things using the icons and prompts presented to you, the way anyone tries to decipher a new program.
As a “pretend new user” you may find, as I do, that success is harder to achieve than you think. I, personally, have seen this frustration up close and personal HUNDREDS of times in the classroom. And I’ve watched many get really angry or simply “give up” (sometimes with tears involved).
Experienced users often don’t understand (or care about) this fairly serious challenge that new users face since they (finally) have figured out simple (or even complex) workarounds. To my dismay, I’ve found that very few people actually ask questions of user forums. Most just give up or move on to another program. My sense is if McNeel wonders why more people don’t use Rhino (a truly phenomenal program in many ways!), they might find that a small handful of initial frustrations are turning some people off to the entire program—and I believe this situation could easily be improved for everyone’s pleasure if there was a will to do so (to wit: The Gumball).
~Dave
Ortho_Issue.3dm (59.2 KB)
I feel that you are arguing against yourself. In this thread you want things to work without having to use any key combinations so that a new user doesn’t have to read the manual or take a class. In the Use of “Set XYZ Coordinates thread you are advocating that more key combinations are added - that probably nobody will find out of.
Yes, I am sure that many new users get frustrated but in the end it’s like learning how to ride a bike; it takes perhaps a week of training and learning how it’s done. That doesn’t make it rocket science.
A lot of the assumptions that you are imposing in that example are just plain and simple pilot error.
That said, have you tried the AutoCPlane script that Pascal wrote and that will be part of Rhino 6 in some form? It makes it possible to work in the maximized perspective view at all time (so that you get visual feedback about where your snaps are going) but still make use of the other CPlanes. In perspective view with the top CPlane active, I can start that line at 0 and then rotate the view until the Front CPlane just becomes active (I would rather rotate to the Right CPlane but the instructions say Front). At this point I can still distinguish between all the lines (they are not hidden by each other) and I can snap to the correct place to end the line. No extra keys were pressed.
AutoCPlane.py (9.0 KB)
Thanks for the heads-up on Pascal’s latest efforts with AutoCPlane. Looking forward to trying this.
Am I contradicting myself? Maybe. But I don’t think so. A fuller explanation (beyond the tedious one above) would be that users could also click the desired snap icons while in mid-command to achieve the same goals I described using keyboard shortcuts.
Personally, I prefer keyboard shortcuts whenever possible, but graphic icons are desirable in addition. If I recall Maya’s behavior correctly, when one held down a snap key, the icon “dimmed” as well. Or one could use the icon instead of the key.
I’m not at all opposed to reading manuals (in fact, I strongly recommend it), however, I’m also aware that learning curves can be steep and memories are not infallible. Admittedly, what I’m proposing might not be the best approach for Snaps or Ortho, but thoughts are welcomed on what one doesn’t like about what is proposed or what might be even better.
Then again. These items might be the height of perfection and there is simply a bad case of pilot error among new Mac users. 
The thing is, I just don’t see the same large uptick in questions/problems related to these issues that you do. And I don’t hold with the supposition that new Mac Rhino users are de facto different then new Windows Rhino users. New users are new users. Period.
For the last 6 years I have taught a raft of “new users” - up to 175 at a time - in my 8 week Rhino class. In the last couple of years the class was more or less evenly divided into Windows/Mac. I never noticed a difference between them in the way they learned/used Rhino. (I did/do notice a difference in other areas)
As Wim said, there is a learning curve for all complex software. They’re not smartphone apps. And yes, it’s sometimes hard for expert users to understand that what looks really simple to them is quite bewildering to someone who has not used the software before. I have often been surprised in ripping through a demo only to be met with a hundred of blank looks…
“Did you get that?”
– “Noooo!”
“OK, where did I lose you?”
– “At the beginning…!”
That’s just the way of it. That doesn’t mean discussions on usability are useless - quite the opposite, they’re welcome. Rhino has constantly evolved over the years, and usability in may areas has improved greatly. But Rhino’s overall complexity has also increased at the same time, as have software performance expectations in general. I don’t have a magic formula for balancing complexity with ease of use.
–Mitch
1 Like
True to some degree. However, Mac and Win working methods, UIX, and accustomed methods can be quite different (especially among those who have used computers, either OS, for some time). That’s why I mention Mac users specifically. The aspects I’m commenting on apply to both OS’s though.
None of us do. The best we can all do is remain open minded and put forward suggestions in the hopes that the issue presented is attacked more than the person presenting it.
This forum does really well with addressing bugs and providing assistance solving problems. It could do a little better with reconsiderations of existing methods, methinks – substituting defensiveness and user-blame with genuine inquiry as to “why” a person can’t figure something out, or seeks a desired improvement. We all win when something is improved.
Cases in point:
A) Ortho does not work properly without additional methods (Tab and/or Alt).
B) Tab is a vital method for Ortho to work, however, even if the user reads the “accurate modeling” page (I’m on my phone so I can’t link it now) Tab isn’t even mentioned.
These both are problems.
I, like others who enjoy Rhino, see room for improvement and am putting forward a few ideas that might help. Perhaps these aren’t ideal, but suggestions are more helpful than dismissal (or attacks) when put forward.
My own back is made of Teflon, but most others are less tenacious. A few years ago, and while I personally liked Rhino, I refused to teach it to new students due to a few navigational shortcomings. I proposed the gumball ideal to McNeel in person to Bob and Steve (which helped) and there was initial skepticism, but some curiosity. What followed was a superb implementation within a very short timeframe. And now this is one of Rhino’s shining stars. We all win when new ideas are thoughtfully considered.
~Dave
@JKayten: Just wanted to commend you on the thoughtful questions and observations. Keep them coming and welcome to the Rhino Community! ~Dave
Well, not to steal your thunder, but some sort of manipulator tool has been proposed by a number of people (myself not included) for many years, along with the usual “I want to be able to push/pull stuff in Rhino like I do in Sketchup”. The advent of T-Splines for Rhino with its own manipulator in 2007 was a strong force as well - especially as the tool also worked on normal Rhino objects - a lot of people said “I want that in native Rhino without having to buy T-Splines !”
–Mitch
All boats rise the more voices that contribute. 
Thanks Dave, I do worry I may be an annoyance at times, but I’m a real fan of this Rhino Thing!
@JKayten: no annoyance at all. You have well considered comments and insights. Don’t be shy at all about sharing your experiences as you ramp up your efforts! ~Dave
Just to clarify, I don’t believe ‘I’ invented the Gumball (the item sought was a well-established Maya-like mechanism) – and nor do I believe Al Gore invented the Internet!
I’m glad to hear of many others wishing for a similar kind of interface in Rhino.
Change, innovation, and improvements often require advocacy. Collective voices usually help and for that reason are to be encouraged.
My desire is that this forum be one that better welcomes (especially new) user frustrations, confusion, and desires – since all of these expressions are opportunities to evaluate whether improvements can or should be considered for collective benefit. ~Dave