Dear Rhino Support Team,
Im using Rhino for Windows and for Mac. Me and my colleguas are the same opinion, that the Windows Version is good and easy to work. We dont’t understand, why you not doing it exactly the same for the Mac Version. The actual Mac Version is really inconvenient to work.
Actually Im sitting on a project where I have to arrange a lot of the same Objects in different sizes. On my Windows Version I have the reference Object and can click on it, hold “alt” and than the object get copy.
On the Mac Version this dont works.
If I have to do “cmd” + V all the time, I will be sitting also next Week on this Project wich I can make in one day with this function.
You are probably still using Rhino 4. This behavior was changed for Rhino 5 (Windows and Mac) - you have to tap the alt key, not hold it down to get a copy. You should see a “+” sign appear to indicate that copy mode is active. This works in both the Windows and Mac versions.
There have been many discussions over the years on this… The fact is that it has been decided to have a Mac-specific interface for the Mac and not a copy of the Windows interface. Whether you like it or not, that’s just the way it is and the design direction taken is not likely to change.
Dear Mitch,
thank you for your fast answer.
I work on Rhino5 on Windows in antother office last week, and there the “alt” tap option works, yes.
Today Im sitting in a office where I only have the Mac Version and I really dont know why it dont works.
I click on the Object, move it and tap the alt key - nothing.
I try also different succession with click/tap and alt key. I also dont see a “+” sign.
How is the correct way to make this possible? Can you describe me in a detailed way?
Im really sorry about my inability!
Yeah, even in Windows… sometimes more than twice… I don’t know why they’ve never figured out why this is happening and fix it, and if it’s happening on MacRhino, it seems like it’s inherent to Rhino, not just a Windows glitch.
Current functionality is not very intuitive, I agree. One must pay very careful attention to the order and timing of select, drag, key actuation to be sure it works–even if you know how it’s supposed to work.
Much preferred is the method: hold down option/alt key at anytime to duplicate, a la Illustrator. If that can’t be done, A close second is to hold down option/alt key when selecting.
Unfortunate side effect of overloading the few modifier keys available in Rhino, holding down Alt toggles osnap behavior and thus prevents snap-dragging to another osnap point if held down while dragging… Which is why the behavior was changed from V4 IIRC.
If I understand properly, holding down “option/alt” temporarily disables snaps during mid-command operations (such as line, etc), right?
(Incidentally, do many people use this feature often? It’s a little unclear of the benefit of this behavior. I can only imagine in my own workflow a ton of accuracy problems if geometry is created without any snaps!)
Several questions:
Instead of holding down the “option/alt” key, is it technically possible to press and release “option/alt” (or any other modifier key, or any other general key) to toggle snaps on or off during mid-command operations? (Note that I’m not asking if this is “desirable”, but rather technically possible.)
If “No”, why not simply assign another depressed modifier key (other than option/alt) to temporarily disable snaps during mid-command operations? This would permit the expected behavior used in many programs of “option/alt” to duplicate items if held down, as the OP mentioned.
If “Yes”, an alternative might be to use “option/alt” as a toggle, rather than keeping it held down. This also would permit duplication behavior while holding down “option/alt”.
If any key (modifier or non-modifier) can be held down during mid-command actions, I encourage McNeel to seriously reconsider the way existing snaps work—since snaps are quite possibly the most cumbersome part of Rhino, affecting virtually all geometry created.
As I’ve suggested before, a system worth considering seriously is that during mid-command operations one could simply hold down a hotkey for the desired snap. For anyone who has worked with this method, it’s difficult to describe how much faster, easier, and more predictable this behavior is than the current method.
(Of course, I welcome insights into optimal use of existing snap behavior (with hotkeys?) that go beyond the mouse-a-lot-click/unclick-a-lot checkbox method. Am I missing a better workflow option here?….)
I use this all the time. It’s important when you are trying to simply move stuff and don’t want to snap to an object (which overrides a planar move and could change the Z depth) but also to keep from picking an object in a dense area when I’m trying to window select.
Ahhh. Right-o…. the need for “option-alt” selection to NOT snap when noodling around. Forgot about this important capability in the current setup.
In the method suggested, the snap state could generally be off, toggled on when needed (with the specific snap that is needed, rather than a set of snaps). This, in large part, is the inverse behavior of the current method, and much more convenient. Also enabling the option/alt duplicate behavior mentioned in Desiprodual’s post. Incidentally, Smart guides could also be toggled on or off independently (and not include ortho, which should be controlled by the “shift” key), rather than a global “all selected snaps” that are either collectively on or off.
So, Jeff and Mitch, do you guys use the mouse-a-lot-click/unclick-a-lot-checkbox-method for snaps, or have you figured out some other more convenient method?
As I work almost entirely in the Perspective view, I leave them on pretty much all the time; I can see what I’m snapping to. I have most of the standard ones checked except of course Near, which is suicide. I rarely uncheck any of the boxes except when one of them interferes (usually “Cen”, sometimes “Perp”); if I need a specific osnap I use the one shots (on my MMB toolbar in Windows). To disable temporarily, I use Alt.
I only disable the osnaps with the checkbox when I’m doing a lot of “eyeball” drag point editing.
I find it interesting that you both largely work in perspective. I, too , favor this workflow, but still rely on four square at times (probably due to nascent perspective navigation skills still ) – and this is where snaps are very awkward.
So, neither of you use “smart guides”?
If so, is this because the recognition of “Ortho” settings in smart guides renders smart guides virtually useless?
At a minimum, it seems that smart guides would largely suffice for the needs we’re describing if Ortho could be excluded?
!!