Wish: Improve the Move command

I have been amazed many times by the way the Move command works. What I mean is that Move always requires that one defines the starting point, even for points (!). Shouldn’t moving a point assume that the starting point is… well, the point itself?

I think so. I think the Move command should have a default starting point as the default behavior, and optionally one would specify the starting point using a commandline parameter “(define start point)”.

For non-points the current need for defining a starting point makes some sort of sense, but even with solids or lines Rhino could be a bit smarter (“intelli-sensitive”) in order to significantly speed up moving objects. For example like so:

  1. Default Start Position: Make the (default) starting point the (gumball) center of the first selected object, or if it’s a point, make the point’s location the starting point (mimicing SetPt in that the starting point is “given”).

  2. Commandline option: When activating the Move command and selecting object(s), the commandline option “Define start point” as an alternative means to complete the selection (on Enter §1 applies).

  3. Default for non-Points & groups: When selecting the Move command, and if the gumball position of the first object is relocated (whether a point or not), then a default starting point would be given ((from the first object), while still providing the option to explicitly relocate the starting point according to §2.

In short, no matter how and what objects you select after activating the Move command, you can directly go to a target point - given that the default starting point is OK. If the default starting point is not OK, the option is there to (re)define it before selecting the target point. This would be a great improvement when making many moves to different positions.

Did I overlook some aspect here here?

// Rolf

Yep, agree with that,

i already asked for this in another thread , not only for move, also rotate, bend , shear, twist etc… should have a center point option , by default or at least in command line.

1 Like

Perhaps. What do you do when you want to move multiple objects? Where is the “default” start point? If you window select objects, no way to know which is the “first” object selected.

I don’t often want to move surface/polysurface objects from their “centers” - as that’s often some completely random point - but rather some specific place on the object that I want to relocate to a new position.

These days I mostly use snap-dragging to move single objects - much faster than invoking the move command.

I do agree that some special-casing might be useful, like for single points.



You are correct, you wouldn’t know.

This is also where §2 comes into play. This option needs to always be there.

To sum up: I think it’s only the default behavior that is questionable, not that there is an option to explicitly (re)declare a starting point.

I think that the windows-case is the special case. In most cases the suggested smarter default starting point would do, speeding things up. In the window-select case it would only take as long as it takes today (but windows select is more of a rare case than moving individual objects). :slight_smile:

The operative word here is “option”. If there is an option to specify the start point, then every time you want to do this, it means an extra click of the mouse or a keyboard press to activate the option before clicking on the “from” point. (because otherwise it will be taken as the “to” point automatically). That will add a lot of clicks IMO.

We can agree to disagree here. With multiple objects, I window select stuff as often as I do mouse select - a quick right to left crossing drag to get several neighboring objects for example… And again, I don’t use the Move command all that often anymore as there are lots of faster alternatives with Gumball and snap-dragging, but when I do use it, it’s specifically because I want to move object(s) from a particular “from” point to a particular “to” point.

Also, I am just not convinced that an object pivot point is all that useful. If I want to move something as simple as a line, its center is generally not the point I’m interested in, it’s one of the ends. But which one? You have a 50% chance of getting lucky there otherwise you would have to reset the pivot in any case. For arbitrary freeform curves, the curve midpoint or bb center is not all that useful either as a pivot point, and if it’s the ends you’re interested in, the case becomes just like the line above.

For surface and volume objects, the most interesting points are probably somewhere along the edges - but again, where? Also to note that the Gumball pivot point itself can take on 3 different locations, depending on whether it’s set to World, CPlane or “Object”


1 Like

I’m totally with Mitch on this one - except that I never use the gumball and never drag to move something. I’m moving things all day long and having to activate a command line option every time doesn’t sound good at all.

I also you move frequently when I need accuracy. An arbitrary “center” point would be meaning less to me, and having to use an option over ride it annoying.

Ops (I agree that that would be annoying, but…), I was actually originally thinking of pressing a second key to activate the command line option, but somehow I forgot that in the original post.

In real life, people apparently use different ways to achieve the same thing, I would benefit from the "default-start-position in probably 80-90% of the cases.

One could also think of swapping the idea about when/how to activate the start-point-option, to that of holding down the ALT-key while activating Move, which would give the default starting point. In Tools | General Options one could select which way it would operate.

Regarding the default position for solids I think one should have a more useful “align” command as a complement to Move. Align and Move, not even Orient, It’s not exactly the same thing. Let the software make guesses, which in most cases as it dos in other software, actually takes care of many if not most cases. It simplifies and speeds up things.

In any case, the current Move command is a forceful annoying extra-click-command more often than necessary. If it makes sense to keep the current version due to different workflows, well, then keep it, but add the suggested way as an option to be set in Tools | General Options. It would make most people happy. Just like it does in other software (as it does in other commands like SetPt, and not to forget in Bongo - the Move Pivot command. It’s self evident, especially for points, that they should not need specifying it’s own position).

// Rolf

Good point. My combination is both Frequently and Accuracy. This actually clarifies things and inspires to putting more thought into how it really should work. So here an enhanced version:


  • Simple case: Use the point’s own location as the default starting point (activate explicit set-start-position option with a special key)


  • When selecting a line, pick near the desired end, or near the midpoint, to “prematurely” select the default starting point. Then, if need be, TAB to jump to :
    • Other end,
    • TAB again to go to the Mid point
    • TAB again to go to the Other end
    • And so on as long as you find it amusing.
    • Pick target point. Done


  • When selecting a Solid, pick near the desired Vertice or Edge (or Mid point on Edge) to “prematurely” select the default starting point. Then, if need be, TAB to jump to :
    • Next Vertice or Edge (ALT-TAB would toggle between Vertices and Edges(?))
    • TAB again to go to the next Vertice or Egde (along Edge, include the Mid point among the Vertices)
    • TAB again to go to the next Vertice or Egde (or Edge’s Mid point)
    • And so on as long as you find it amusing.
    • Pick target point. Done


  • Or go to Tools | Properties | General and simply revert to “Old Style Annoying Move Behavior”. :slight_smile:

Aren’t we onto something here? Accuracy is the most common problem when picking Points or Line Ends in a mess of nearby Points and Line ends. With this behavior all accuracy problems are gone, and in most cases (picking nearby the desired end, Vertice, position on Edge) the start point would be guessed correctly on most cases, say in 90% of the cases. Mission solved.

I do think we are onto something here. And perhaps not only for the Move command.

// Rolf

Just keep it simple. Select what you want to move. Select where you want to move from. Select where you want to move to.
I use this command many times a day, quite often to re position something without reference to the moved geometry. I would prefer to see the selection method remain unchanged.



Simple is exactly what it is not as it is now. Bad precision and slowing things down. Picking a point, on a point, on a line or on a solid with the mouse always takes precision, and it takes more precision (and time) than if the point is provided by software, either as a pre-select (as described above) or by tabbing to the correct end, vertice or edge.

Especially when there are many points or lines nearby, you are prone to pick the wrong position. Tabbing to the right pick-point - while having the opportunity to confirm the object identity in the property inspector - would do away with any uncertainties or bad precision. Apart from being so much faster workflow.

And if those 100% precision (TAB) alternatives are not enough, press the ALT-key to enable the (old) option to explicitly pick a point with the mouse (as it works right now). Or disable the new better suggested Move version altogether and use the currently behavior instead (and waste time and precision :slight_smile: ).

I understand that what you’re used to may seem the most convenient. I can say that I am also already used to the current behavior. But every time I switch to using some other related software and switch back, I’m again amazed at the current behavior. Every time it seems odd. But Rhino Move can be so much smarter (lets call the new behavior “SmartMove”, or “SMove” :slight_smile: ), while keeping the option to do it the old current way.

// Rolf

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