Use of "Set XYZ Coordinates

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.

–Mitch

Brilliant, Mitch!

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!

~Dave

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.

That’s actually a nice work-around.

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!

~Dave

fwiw, i use a macro for that (alias MV)

move pause vertical 0

you just enter an positive or negative distance and it moves vertically that amount.

i guess i wouldn’t consider it an intuitive solution but once learned, it’s fast and easy.

why not put them on a keyboard shortcut?

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.

You don’t need to toggle the persistent snaps off for this. Entering a one-shot snap will override the others.

Will do some playing around with all this. Thanks for the suggestions! ~Dave

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… :confused:

Max.

that’s pretty much the same way i work… center is off but i occasionally need it… the macro i use is

Osnap Center Enter

that will toggle between center being persistently on or off.



[edit] @maxz

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.

–Mitch

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:

Before selecting line start:

After selecting line start:

Unfortunately, that does not function in the same way on the Mac.

@jeff_hammond: Thanks for your suggestion, but that seems a bit too rigid for me, I would like to be able to vary my persistent snaps.

Max.

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…

Yes, another McHandicap… Sorry.

–Mitch

Hi Mitch, i didn’t think it was that big…
However, I did it my way… :sunglasses:

(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 … :grinning: Just what I wanted!

Thanks.

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”… :blush:
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.

Max.

…and a serious handicap I would say…
I hope that fixing this would make it to the top of the list very soon! @dan, @marlin

Philip

2 Likes

What command is issued when doing this in WinRhino and could this be done somehow with shortcuts or aliases in MacRhino?

The closer I get to figuring out a useful workaround, the further away I seem to end up.

It would be really wonderful if snaps would someday go beyond multi-step methods that eventually can be coaxed into doing what one wants, to a more fluid behavior that aids the drawing process rather than continually disrupting it.

My guess is that persistent snaps aims to do this. The problem arises when one wants to force a desired snap and it’s not “one” shot, but two or more.

Forgetting existing Rhino methods/terms/etc for the moment, but thinking of potentially ideal working methods, ideal behavior might be:

  • to draw with smart detection of all possible snaps or desired snaps (rhino does this fairly well)
  • temporarily, and easily, over-ride this condition for as long as is desired with a preferred snap. (Rhino does this somewhere between awkwardly and not really)

The most fluid method I can imagine is, while drawing (or “in-command”) when one holds down a key (or combination of keys) a desired snap takes priority and the smart detection snaps are over-ridden. Release the key(s) and the prior smart detection state resumes.

Does the key(s) need to remain depressed while in-command for this to work? I sort of am wondering if the answer is yes, since any other method using release of the key invokes a toggle state that one has to toggle again to restore the previous state of persistence versus one-snap, etc.

In other words, our efforts to come up with an improved solution might be based upon a flawed premise of using existing routines.

Can Rhino currently, or in the future, accommodate a key(s) being held down during in-command to create the snap behavior described? I think of the shift key for Ortho, and suspect maybe? ~Dave

This is stuff habitually buried deep in the C++ code and not exposed to the user as a command… I can say that the Osnap states are exposed in RhinoCommon, thus scriptable, but as far as I know (someone correct me if I’m wrong), it’s not possible to run a Python script while currently inside a running Rhino command. Perhaps a plug-in structure might be able to do it?

–Mitch