Change in behaviour — Moving Objects with TAB-Function toggled

I noticed that the function of “locking the direction of movement” with the Tab-Key has changed behaviour in v6 beta — in a rather inconvenient way, at least concerning my workflow.

e.g.: In rhino 5 when you wanted to move an object vertically by “locking” the movement along a vertical side with the press of the Tab-Button you could enter coordinates and the object would align itself to these coordinates but within the constraints that you imposed with the tab key.
In Rhino 6 the input of coordinates (sadly) overrides the Tab-Key-Constriction and it just pops to the coordinates which I think defeats the purpose somewhat.

If you couldn’t grasp what I was trying to (poorly, I’ll give you that. ^_^’ ) convey, refer to the pictures:

A 5x5x5 with the corner closest to origin located at (-2.5,-5,-5). The red mark is the vertical edge of that corner projected to the CPlane.

move-command in Rhino 5, from that corner with TAB-Constraint; entering (0,0,0) as coordinates into the command line.

Still Rhino 5, hitting enter. See how said corner lines up with the red mark, even though (0,0,0) was entered.

Now Rhino 6, same situation: Move-Command, corner close to origin at (-2.5, -5, -5) at the start. Tab-Constraint (white line visible!) along the vertical edge of that corner. Entering (0,0,0) as coordinates, but now the box jumps there as a “preview”.

“Enter”… see where that box went. I don’t know if that change in function is deliberate, but at least for my workflow it is a bit sad, as I see the Tab-Constraint one of the best basic functions in Rhino for quickly aligning stuff…

Hope to get an answer to this.
Until then, Thanks for your hard work!

Thanks for the report! Type 0 instead of 0,0,0 in v6 to get what you expected. Does that help?

It actually does.
That just solves one instance (“move to height of origin…”) of a general problem; If I type (1,1,1) to align that corner to a point at 1,1,1 then it “breaks” the constriction again and moves the corner there. If I type just “1”, understandably it moves in the direction of the constraint by 1 unit. so… ^^

Can you provide a 3dm file with the steps you’re performing in the new set up? I’m getting lost trying to recreate the scenario where a tab constraint is used for direction but that direction may or may not be crossing 1,1,1.

Constriction_explanation.3dm (221.1 KB)

I added explanations as text in the file, hopefully you can recreate the problem now.
Simply put:
Typing in Coordinates while in “TAB-Mode” aligned the point along the constraint-line with the coordinate in v5.
Typing in Coordinates while in “TAB-Mode” does now override the constraint completely and just executes a “normal” move-operation.

let me know if I can be of further assistance!
thanks again.

Perfect, thank you. I’ve filed this as

Wonderful! Then have a good evening now. :slight_smile:

While we’re at it; one thing I always found very useful in that otherwise usability-nightmare that is Blender:

When Moving an object you could press [X], [Y] or [Z] for constraining the movement to that axis, or [Shift]+[X], [Shift]+[Y] or [Shift]+[Z] to constrain movement in the YZ-Plane (XYZ Minus X), the XZ-Plane or the XY-Plane respectively.
It also worked with rotation (Pressing the button locked the rotational axis to the respective dimensional one) and Scale1D/Scale2D.
I do not know whether there’s copyright on that feature but it was the one I loved the most for the minuscule time-frame I tried to make sense of that program.

Just my 0.02$.

I’m actually a fan of Blender second only to my fondness of Rhino so I know what you mean about those shortcuts being helpful. In Rhino the Gumball is used for these types of movement constraints. I don’t anticipate or haven’t heard any talk about mirroring these shortcuts in Rhino. With that said, if enough user’s said they wanted it then it’d more likely get developer attention. Feel free to start a separate thread here to see if there’s any traction for the idea. Also try the Gumball and see what you think. Click and release over the manipulator handles also allows for numeric input!

1 Like

I guess I just never could get used to the “right click to select” feature. hehe.

Allright! Will try it, but I found the fact that it does not need a visual thing possibly obscuring small parts or being in the way of the cursor (“crap, didn’t mean to enter values, wanted to click that minuscule thing sticking out behind it”) very elegant.
(Also, the numpad-functionality for cycling through views… yummy.)

Have a good night!

Shortcuts are fine, but only if they are an addition to the regular UI.
There must be always other methods to invoke what a shortcut should do.
Or at least a very visible hint.

I don’t want to see Rhino becoming as obscure as Blender is.

Agreed. But as we have that nifty command line up there, where we e.g. could go from:

Point to move from (Vertical=No): [V should be underlined.]

to maybe:

Point to move from (X-Axis=No Y-Axis=No Z-Axis=No), something something…

Blender is hard to grasp at first, I’ll give you that very readily…

But we already have the Shift constraint for that.
In combination with the OneView command, you can easily restrict working in any of the 3 planes…

1 Like

Learn something new everyday. Didn’t know the OneView-Command. Thanks!