Move settings

Far more helpful than this one especially if you didnā€™t know one could do that and avoid the red rotation handles.

1 Like

Well maybe I was too harsh, but the notion that you donā€™t ā€˜needā€™ to click the object when moving is an assumption that ignores the ā€˜needsā€™ of the user, and incorrect since clicking the object is necessary for vertex snapping at least.

1 Like

Itā€™s just a simple fact that if you choose you can execute a move operation without clicking on the object. Sometimes this is very helpful when moving lots of small objects around like this. Believe it or not, I was trying to help, knowing I could not magically make the handles go away. So I suggested trying something that would or could be of use. It was not a dismissive or defensive suggestion, and it was anything but unhelpful. I am a seasoned sketchup user with a lot of experience, and nothing about my comment was naive, thank you very much. And to imply Iā€™m not understanding the issue is, well, naive.

1 Like

Doesnā€™t work for Scale, either. Just saying . . . :slight_smile:

1 Like

somethings up with angles when using the rotate-in-move.
I start rotating, type 90, hit enter, and get 180.
Untitled

There is subtlety at work here. Unlike the rotate tool which begins all rotations at 0Ėš, the rotate handles of the Move tool are relative to the objects bounding box position and also relative to the global axis, giving this tool different capabilities and uses. For all objects 0Ėš of rotation is on the right hand side, or 3:00. When viewed from the top this is outward along the red axis. , 90Ėš is outward along the green axis, 12:00, or 90Ėš CCW. Negative 90 (-90) is out the dotted green, and 180 and -180 are the same direction, out the dotted red axis form the top, or 9:00. For the various sides of the bonding box (like the bottom) this can be reversed, but 0Ėš is always at 3:00. Each red handle of a given object starts the rotation from a preset degree position relative to the global axis, and that degree position is determined by its location relative to the bounding box and the global axis. If you change the global axis, 0Ėš will change accordingly. Perhaps Iā€™m doing a bad job of explaining, I feel like Iā€™m making it sound more complicated than it is, but itā€™s a use-full feature. The take away is that like so many tools in SketchUp, where you grab the object matters.

So what you do in your example is grab the -90Ėš handle (see how the VCB starts at -90 when you click to start), and ask that handle to move to the 90Ėš position which is effectively 180Ėš of rotation relative to the object. If you had grabbed the 0Ėš or the 180Ėš handle and typed 90 you would have moved either of those to the 90Ėš position, 90Ėš CCW or CW respectively. If you grab the 90Ėš handle (green axis or 12:00) and type 90Ėš you get no move, because that handle is already in that position.

This this behavior of the rotate aspect of the Move tool allows of a different set of uses and workflows than the Rotate tool.

3 Likes

wow. IĀ“ll read it again in broad daylight :slight_smile:

3 Likes

And donā€™t forget your coffee!

  • the entered angle values are all relative to the current drawing axes. (as mentioned by @endlessfix )

Iā€™m trying to demonstrate how grabbing certain grips affect the results.

1 Like

Playing with a labeled object helps to understand the relationship of the global axis. The handles reset each time you use them to be relative to the global axis, so for each fresh move, the handle at 3:00 is 0Ėš, regardless of previous moves. The values you enter relate to a constant existing protractor which is set by the global axis. This is unique to the move tool and has many uses.

1
1

2 Likes

Clever trick :slight_smile: I use hidden geometry and guide points to place snappable points inside my components for use with the rotate tool, but your trick is a neat way to do it in a variety of different scenarios.

2 Likes

I do that too, also a good trick. :slightly_smiling_face:

The bounding box is set by the perimeter of the contained geometry, regardless of complexity. I start a rectangle drawn on center from whatever the desired axis center is and make it just slightly larger than anything else contained. Fun!

1

3 Likes

Heads up! This is going to be a Skill Builder!

5 Likes

I do have to disagree on several points.
The axes that matter are the current drawing axes (or is this what you mean by global axes? Opposed to SketchUpā€™s systemā€™s axes) in which the group or component resides. And of course the groupā€™s / componentā€™s own local axes.
An entered angle (0 / 90 / 180/ or 270) will always align the group allong current drawing axes.
0 ā€œbelongsā€ to the first grip / local red axis
90 to the second grip / local green axis
180 to the third grip / local dotted red axis
270 to the fourth grip / local dotted green axis.
Whatever the previous rotation(s) may have been, entering 0 applied on the first grip will rotate the group to where local axes and current drawing axes will correspond.
However, applying a rotation on the second grip requires a value +90 to achieve the same result.
For the third grip this would have to be value +180. And for the fourth it would be value +270 to align local axes with the current drawing axes.
Irrespective of how many previous rotations there have been made.
For other rotation angeles it is a matter of applying value +? depending on the grip you pick.

I donā€™t think we disagree really, Iā€™m just doing a poor job of using language :face_with_diagonal_mouth:. Yes, the axes of whatever context the object resides in is what determines where the degrees are set. For first level objects that is the global axes / drawing axes / world axes (as you say, not the un-alterable system axis). For anything nested itā€™s the local axis of itā€™s context.

I think we are basically saying the same thing although I guess I donā€™t think of it in quite the same way. I consider each grip to have itā€™s own position. Like you I associate each grip with a degree position (although I use -90 instead of 270 as thats what the VCB calls it, but itā€™s the same thing) Then when entering a value I think about where I want that particular grip to go. So no matter which grip I grab, if I type 90Ėš I expect that grip to end up on the green axis.

Hmmmā€¦ this is confusing to me it makes it sound like there is a ā€œfirst gripā€ that should be clear when working. I guess you are calling the ā€œfirstā€ grip the one that is along the red direction contained within the component/group, is that what you mean? But how do you know which one that is without opening the container? When working I consider each grip to inherit the degrees it is set to in the VCB, which is always Red axis at 0 no matter which way the object is pointing. This is what I mean by the grips/handles resetting each time the 3:00 grip (or vector) is 0 regardless of the axes orientation contained within the container you are moving. So functionally for me entering 0 on the first grip does not align the axes to correspond, it moves the grip that was clicked to the 0 position. What you say is true if you happen to grab the ā€œredā€ or 0 grip of the object, but AFAIK there is no way to tell that from outside the container (unless axes are set to visible, bleh :nauseated_face:)

I suspect this is potatoe / patahto and just different ways of describing this behavior, and as I said my struggling for the the correct language. I probably have a backwards, bizarre, inside out way of thinking about it, I usually do.

Some years ago I tried to explain the principle of this to someone who insisted there was no way to align an organic shape back to the correct alignment once rotated, they never managed to grasp the concept. It became quite heated from their side, as is often the case on the internet.

Not here, for we are friends.

2 Likes

I agree with this request. That unwanted ā€˜rotateā€™ annoys me a lot too, which I touch without meaning to many times, and which I NEVER use, because to rotate I use Rotate command. I find it very obtuse, keep asking for ā€˜a good reasonā€™ for the request - just use sketchup to figure it out. The logic is very simple: how many use those grips to rotate? How many use rotate command? How many are annoyed by unwanted activation of those grips?

2 Likes

The ability to disable them would perhaps be useful to many, but to remove them altogether would be like cutting one arm off.
There are far more important things I would prefer they address.

2 Likes

Another upvote for this request. I have never once wanted rotate an object after selecting move. I select move to move. I select rotate to rotate. I typically want to move things very precisely ensuring I have selected a vertex and snap vertex to vertex. If I am in a large model and trying to move small parts (i.e. bolts etc.) those red handles get in the way all the time. They can sometimes appear as large or larger than the component itself! Having to zoom all the way in to find a bloody vertex and avoid them drives me nuts and can often induce plane clipping. Anyone else love a bit of zoom plane clipping in Sketchup?

I can appreciate they may be useful for someone quickly free form modelling (@Box), but for people moving and placing boring orthogonal objects of all scales, from a roof to a bolt, all dayā€¦ they are extremely irritating.

Ability to disable please.

1 Like

when dealing with skinny objects like pieces of timber, bolts, etc, its often ecessary to zoom right in so that accidental rotation of said skinny objects is avoided.

+1 for making it something we can turn off in preferences.

i will add this:
users that remap tools to focus on WASD (w=move) plus QERFZX (R= rotate) have all the common tools under one set of fingertips.
Assists like the move/rotate widget are not needed or desired.

1 Like