Wish: Improve the Move command

Rolf- if you find what you describe with Move command more useful, simple macro or script can get you there. I definitely prefer the command as-is for precision and would not try to fix what’s not broken…



Keeping as is for precision is not a valid argument against an alternative that would always give 100% accuracy (using TAB).

Problem is of course that picking with the mouse IS inherently lesser precision compared to alternative ways (like suggested above). The lesser precision you get with mouse clicks is common wisdom taught as a basic truth in UI design. And they go on to explain that the extra effort required (deeper concentration) for reaching acceptable precision with a mouse is tiring. Compared to alternative ways, like tabbing (or some other approaches like big fat mouse-over highlighting effects that intends to lessen the precision required to hit the target).

Why they try these kinds of approaches is because the precision argument simply isn’t valid.

Having said that, It’s not that I don’t understand that people may prefer the old way, but for other reasons than precision and speed. And for that reason I see a good point in not making this suggestion into an either-or-thingy. but instead I suggest to keep the current approach as a General Settings for those who prefer, well, the lesser precision and slower workflow.

It’s not that the problems involved with all the precision mouse-picking isn’t a well known, instead the question is which solution(s) gives better and quicker precision results, even without tiring people out.

I think there’s some good ideas in this thread about how to fairly easily improve the UIX in this regard.

A script certainly should be able to do all the tricks, and when I have the time I may try to code it myself (for now I’m not skilled enough in reading the object info, so it would take some learning time).

// Rolf

Not sure why you make it sound so complicated… I use OSnaps 99% of the time when moving (even if it’s not ON, pressing ALT gives me a temp override ) and I get 100% accuracy, fast, that way. Hardly ever need to move from a completely arbitrary point, so OSnaps give me exactly what is needed.

1 Like

Now you don’t address the alternative. It’s only a comparison that makes sense when presenting or questioning a suggested alternative (or addition). This means that simply stating :

  • “fast”, doesn’t say very much if not putting it in relation to something else. In this case “fast” has less significance without the comparison to the alternative method I have suggested (direct hit in 80-90% of the cases - compared to 2 clicks, and the need for concentration to get the precision in 100% of the cases in the current behavior). I think I’ve fairly been clear about that by now.

  • “Accuracy” is also to be compared with the suggested alternative way, in which neither one(1) click (instead of always two (2)) clicks and 100% accuracy doesn’t take the same effort, nor the same time.

Notice that I suggest double speed at 100% accuracy with lesser effort (lesser need for concentration and thus less tiring over the course of a day’s work).

Of course I also use OSnap as well. But as indicated I often do not get 100% accuracy without deep concentration (it also depends on what you are doing), and when I fail at first attempts also I eventually always arrive at 100% accuracy, just to point out that accuracy without comparing methods doesn’t show what I’m out for here (I mean, what is eventually possible, even in hard cases, is not the topic here, instead it’s about speed/accuracy/lesser effort at first attempt. All of it at once).

But I don’t think it’s useful that I repeat over and over again what I already mentioned several times in this thread, reasons which appears both real and significant enough to motivate others trying to find ways to make UI’s better and faster.

// Rolf

Can you explain what you mean by “snap dragging”? Are you using the gumball?


Try the first experimental version here. It covers the basic idea, but not all the features as of yet.

// Rolf

No. No gumball necessary. Just have object snaps enabled, then select an object, go towards the end or near the spot you want and press and hold the left mouse button. After a tiny delay, the object snap will light up, then continuing to hold the left mouse button down, drag the object and snap it somewhere else and then release the mouse button.

Quick vid



Excellent tip!

Aha, I’ve never seen this behavior before! That’s very useful.

I guess this behavior applies only for one object?

// Rolf

Nope, you can preselect as many objects as you want. --Mitch


i don’t think ‘assume’ would be the right word because i’ll sometimes move a point with start/end locations not being the point.

that said, i do think it’s probably a lot more common to move a point from it’s own location.

(just chitchat… not meant as a pro/con towards your request/idea)

I frequently use the origin, shortcut “O”, as the starting point for a move. The second "point"coordinates are the distance increments I want to move the object.

O (for origin) as the first point and 2,0,-5 causes the object to move 2 units in the x direction, 0 units in the y direction, and -5 units in the z direction. This is the the same move as snapping to a point on the object as the first point and R2,0,-5 as the second point. The same move can be done using the Gumball by clicking on the x move arrow and typing 2, and then clicking on the z move arrow and typing -5.

Yup, I do that sometimes too. But that is very well supported by the std Move command. :slight_smile:

And yes again, the word “assume” wasn’t the best choice of word. Most often isn’t exactly the same thing as always.

Same here. But then there are all the other cases as well.

Anyway, the behavior which Helvetosaur pointed me too looks interesting as well. I will try it out for a period of time to see how well it covers the idea I had with SMove. I could tell directly that it’s useful, I know that much.

// Rolf

the gist of your wish could also apply to the Paste command… (as in copy/paste)
sometimes you want to paste in place (current behavior) but other times, you want to paste to the cursor. (instead of Paste then Move)…

for consistency down the road, the same ‘rules’ should work with the SMove as would work with PasteToCursor in regards to where the cursor is initially locked on to the object.

Yes, that would be great. But I guess that in most cases the copied selection would have an unknown(?) start point to be moved to the cursor. But the Copy-SMove command could start just like the SMove command, then selecting the target point would be no problem.

One could also think of just tapping CTRL while in SMove, in order to drop a copy of what’s in the Clipboard.

There may be more and better ideas.

// Rolf

just by the way…
if you tap Alt key while dragging as Mitch suggested, a copy will be moved instead of the original… so in that sense, there’s already a copy&move tool in rhino.

also, cmmd/CTRL key will force vertical dragging (i often wish for that functionality across all commands :wink: )

Thank you for this hint, this is exactly why I shouldn’t suppose no one else has already thought of things before I did… :slight_smile:
Knowing this I will have yet another aspect of it to try out when examining that approach to see what it covers.

And yes, it would really be a great thing having this kind of stuff consistently implemented in every command where it’d make sense. Subject for a “x.5 version” of whatever Rhino version around. Really.

// Rolf

What about a grab command.
Does that exist or was it mentioned already? This would function like the Blender grab “G” key. It reads the selected object(s) origin and locks the objects to the mouse, objects can be constrained by hitting, X,Y, Z depending on the axis you want to constrain, if you want to constrain. They also allow for a shift+“axis” key command to allow all directions but that axis. Typing a numeric input then moves the object that much if a precise movement is needed.

Works the same for scale and rotate and is fast once you are use to using it.

1 Like


a lot of that is already in rhino and the functionality applies to all/most commands…

Shift key will put the cursor on the nearest ortho (if you have ortho set to 90º, it will lock to X or Y axis… or change the angle to lock to, say 45º, then you’ll get X&Y plus the axis in between those two)

Tab key will lock the cursor to the axis it’s currently on. (either via the shift key method -or- inferencing etc.)

you can type the distance in conjunction with these (and most other things in Rhino).

idk, it’s not exactly the same due to UI differences but the ability is in there… pretty sure shift and tab are two of my most used keys during modeling.

Thanks Jeff!

I have been trying to find or get a “grab” key/function to work. Do you know if there is a command or plugin out there for this?

It basically allows for the release of the left-mouse button and grabs hold of object(s) while moving them.