But true, Rhino does not have the notion of a fixed object “center” that stays attached to the object. That might make sense for some objects, not for others. BoxEdit and Gumball use the object bounding box center, which again makes sense for geometrically regular objects like circles, rectangles boxes and spheres, but not much sense for odder shapes.
If I want to move something up by 1 unit (or whatever distance) I do the following:
Gumball - click on the “up” arrow and type “1” and Enter. Negative numbers move in the down direction. Idem for all the other axes, plus there are the scale and rotate handles. Alt while doing any of this creates a copy. I don’t see it getting any easier than that. There are scripts and macros that I also have for common moves like rotating one or more objects 90° in either direction, 180°, mirror across one of the axes, etc… All a couple of letters and Enter.
Based on what you’re saying (and if I’m reading this right), it seems like In-Command shortcuts for snaps (which are preferred) might actually be easier than Pre-Command shortcuts since the list of possible actions associated with a key is considerably narrowed down in the sub-routine of the in-process command. Correct?
I’m not sure why I can’t find the original thread on this topic (where Pascal first thought Aliases would work, but following my tests also found that Aliases were not a reliable solution). I can’t remember all the glitches now, but here are the Aliases I tried:
x = _IntersectionSnap
c = _NearSnap
m = _MidpointSnap
v = _EndpointSnap
If you care to do some testing, I’d be interested in your thoughts.
Ortho: In my example file above, even when working in Perspective mode (which I also prefer to work in), Ortho does not constrain the line solely to orthogonal behavior. (Draw a line from the point with Ortho on, and if you get near the line that is not at 0,0,0 it will snap to the end). The only difference working in Perspective mode is that it “may” be easier to see this behavior—assuming one does not have a lot of close proximity geometry. If one puts the two lines very close together, one has no way of knowing if the Ortho action is reliably selecting the proper point.
It’s this last part that captures the serious flaw with Ortho behavior currently. I can think of no instance where the desired behavior of any tool relies entirely on visual verification AND/OR simple geometries. Conversely, I can think of (and have experienced) countless instances where visual verification is impractical and complex geometry is unavoidable.
With people increasingly fabricating items directly from digital files, the fact that this command does not always perform orthogonal actions (which people may reasonably presume is the case) can easily result in some rather costly errors. Rhino does many complex operations extremely well. It is unclear why such a simple operation—with so much potential for serious errors—A) behaves as it does, and B) is not a high priority for improvement.
While Ortho may not affect you, personally, do you see how this could be a pretty serious problem for others?
In the commands where there is no conflict, they seem to work OK here… However, conflicts are pretty much everywhere… Just after about 3 minutes exploration:
x=_IntersectionSnap won’t work with Line as x is a command line option (eXtension).
c=_NearSnap won’t work with Ellipse (Corner), plus a bunch of commands that have a Copy option.
v=_EndpointSnap won’t work with a number of commands like Move which have a Vertical option
etc…
Edit - it may be better to work with 2 letter aliases which are much less likely to be used somewhere.
For example xx for intersection, cc for near, etc… If I do that, I have no trouble using those aliases for in-command osnaps. However, I still find that just hitting the thumb button (which is my MMB) and popping up the one shot osnap pallet works faster. In Windows Rhino the pallets are far easier to customize than on Mac, and all you have to do is hold the MMB down, hover over the snap you want and let it up and it’s active.
I didn’t realize that the reason the single letter Aliases were glitchy was due to In-Command shortcuts often competing. Given that this is the reason for glitchy behavior, and not some other technical reason (as I thought), using double letters never even occurred to me.
I reassigned double letters for each snap and tried it out. While drawing, I can now type the desired double letter and hit the spacebar (for enter). Major, major improvement!
FWIW, I just use the default abbreviations when I want to snap to a certain feature: cen for center, pt for point, e for end, … My mouse stays in the position where I am working and I don’t have to think where I place my hands on the keyboard, so for me that’s the simplest way…
And as for that one, I work with ortho off. When I want ortho, I hit shift and tab to lock direction and snap to geometry without the ortho lock being overridden.
It does exactly what Ortho should do without the extra steps or knowledge of Tab (which seems cleverly hidden in introductory resource material for new users). I actually never thought to try this, so thanks for the tip!
use option x, option c, etc as the keystroke (option key is free for all of the letters you listed above)
then you just hit the keystroke and it happens… without double letter aliases or enter.
and since you’re using a modifier key along with the letter, it won’t conflict with the command line.
that way seems almost exactly as you asked for earlier
“Desired behavior, in addition to existing methods (likely not “instead of”) is: While geometry is being drawn (such as the second point for a line), one could “on the fly” simply toggle a key (meaning: “tap and release”—or, I guess, one could even hold the key down) that serves as a keyboard shortcut for the desired snap. Optimally, one could also change one’s mind mid-routine, pressing a different snap shortcut before selecting the second point”
@jeff_hammond Yes! A custom keyboard shortcut works as well. If one can get the right combo, this might even be better than Aliases due to not needing to hit enter. (Because I can’t export my dang custom keyboard shortcuts as a reference, I’ve been loathe to add any more, so didn’t think of this approach).
The only drawback I’ve realized to both keyboard shortcuts and Aliases is that one has to actuate the chosen snap prior to each cursor click, unless one uses persistent snaps (which creates some other oddities). The desired snap behavior would be sticky. Once one enters a snap, it would stay on In-Command until or unless one entered another desired snap. I can “almost” get this to work.
Curiously, a combo of persistent and regular snaps seems at first blush to work acceptably in a toggling kind of fashion. I assigned the following keyboard shortcuts in a brief test:
Option + Q to Persistent End, Point, Mid, Cen,… (Note this is the only persistent snap chosen)
Option + V to OSnap End
Option + S to OSnap Near
Option + X to Intersection
Option + C to Center
Option + M to OSnap Midpoint
The thing that seems to work reasonably well here is that one can use the all-purpose persistent snap (which generally works pretty well), but easily toggle these off if a more specific snap is needed (such as the rare case where Near is desired). Then one can toggle them back on.
This method seems way faster than the under-mouse-pop-up. Will have to live with this for a little while to see if further fine-tuning makes more smiles or not.
Good suggestions, folks! If ya’ got any more good strategies, I’m all ears. ~Dave
you might be better off using the Osnap command with the None option… (if i understand correctly… only wanting one snap on at any given time but that snap stays sticky until you change to something else?)
if the macro is just
Osnap None
then you just use the underlined letters in the dialog to choose.
or you could use:
Osnap None Endpoint Enter
to specifically activate only end snaps.
or combinations if you see fit:
Osnap None Endpoint Intersection Enter
personally, i usually model with all of these on:
if you have a similar ‘personal default’ set that you use, you might want to make an alias/keystroke for it so you can get back to it easily… because the above Osnap macros will clear your panel except for the snap in the macro.
I’ve been reading this thread with interest, but I am still puzzled how it all can be made to work in my case. What I would like to achieve is the following:
I am using 5 or 6 persistent Osnaps, not including Center. On occasion, I would like to use the center snap exclusively (but not necessarily as a one shot), then return to my regular Osnaps. What would be the command macro to use as the result of typing an alias or as keystroke macro?
I have tried the “none” option that @jeff_hammond suggested, but as a result I have to reinstate all my regular Osnaps afterwards.
FWIW: I am not worried about ortho being overridden by Osnaps, but I am happy to learn about the Alt-key to disable snapping temporarily. I also managed to miss the use of the Shift-key as a temporary ortho restriction…
that said, if you want to use osnap center exclusively but not as a one shot, you’d need two macros…
Osnap None Center Enter
(which will set persistent snaps to center only)
then another macro:
Osnap None Endpoint Point Midpoint Intersection Perpendicular Enter
which will disengage center and set the Osnaps back to your ‘normal’ snaps.
(i used those 5-- end, pt, mid… as example… type/replace the ones in this example macro to your defaults)
For a one-time use, it’s easy as you know, expressly invoking a particular snap overrides all other persistent ones for that pick. However if you want to do a persistent center snap and exclude all others, you will need to actually modify the settings in the Osnap box. The way to do this (on Windows Rhino in any case) is to right click on the Center osnap, which will turn all others off and Center on. If you right click again on Center afterwards, it will turn Center back off and all other snaps you previously had set will turn back on.
That is not what I am encountering. Typing the Osnap command brings up the options. I select the “Center” option, but that does not suppress all the other osnap options that I already selected:
I can pick the One Shot option here, which does indeed allow me to exclude everything except the center snap, but after the first snap the normal situation is restored, i.e. all the persistent snaps are available again, even though the One Shot option remains selected:
If you want to have a one-shot “Center” osnap that overrides others, use the Center osnap button from the Osnap tool palette and not from the Osnap panel. Unfortunately, Mac Rhino does not make it very convenient for you because by default you pull down a HUGE menu from that button (takes nearly my whole screen vertically here), and Alt+clicking on the button within a command doesn’t work at all to show the buttons and not a menu… Edit: actually it does work, but you do need to hold down the button for a bit longer than I expected. And of course the Osnap pallet flies out, but stays out, does not close automatically. Sigh…
(full Alias text: _ShowToolPalette _ToolPalette=MaxzSnap _UnderCursor=YES _Enter)
Now I can open the palette I made, under the cursor, and pick an Osnap exclusively that I don’t have as persistent, without upsetting my persistent Osnaps … Just what I wanted!
Thinking about it again… it is a bit the same as what I used before, isn’t it. When I leave the One Shot option selected, then pick an Osnap option, the same happens as I described above as my “new invention”…
But there are advantages: I don’t have to reach over to the left/bottom panel with my cursor ( I have a 27" iMac !), and I can still toggle the Project snap on/off without having to return to the Persistent Osnaps first.
Just what I wanted!